<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Mar 17, 2016 at 9:08 AM Tom Barber <<a href="mailto:tom@analytical-labs.com">tom@analytical-labs.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Its taken me about 2 weeks of on and off testing to get 4 unit tests working, getting everything to play ball is hard, so it would be good! Maybe I'll write a blog post about it once I'm done.</div></blockquote><div><br></div><div>Fantastic! Do you have a link to these? Would love to see how these</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"></div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr"><div><div dir="ltr">--------------<div><br></div><div><div style="font-size:small"><font color="#999999">Director Meteorite.bi - Saiku Analytics Founder</font></div><div style="font-size:small"><font color="#999999">Tel: +44(0)5603641316  </font></div><div style="font-size:small"><font color="#999999"><br></font></div><div style="font-size:small"><font color="#999999">(Thanks to the Saiku community we reached our <a href="http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/" target="_blank">Kickstart</a> goal, but you can always help by <a href="http://www.meteorite.bi/products/saiku/sponsorship" target="_blank">sponsoring the project</a>)</font></div></div></div></div></div></div></div>
<br></div><div class="gmail_extra"><div class="gmail_quote">On 17 March 2016 at 12:24, Merlijn Sebrechts <span dir="ltr"><<a href="mailto:merlijn.sebrechts@gmail.com" target="_blank">merlijn.sebrechts@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">As an aside; is there a good write-up somewhere about charm unit testing. I'd like to do this but I'm not sure how to do this. I am completely new to unit testing so I'm having a hard time to see how a good unittest for a Charm would look like and what exactly should be tested.</div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>2016-03-17 1:52 GMT+01:00 Marco Ceppi <span dir="ltr"><<a href="mailto:marco.ceppi@canonical.com" target="_blank">marco.ceppi@canonical.com</a>></span>:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">Hello everyone!<div><br></div><div>This is an email I've been meaning to write for a while, and have rewritten a few times now. With 2.0 on the horizon and the charm ecosystem rapidly growing, I couldn't keep the idea to myself any longer.</div><div><br></div><div># tl;dr:</div><div><br></div><div>We should stop writing Amulet tests in charms and instead only write them Bundles and force charms to do unit-testing (when possible) and promote that all charms be included in bundles in the store.</div><div><br></div><div># Problem</div><div><br></div><div>Without making this a novel, charm-testing and amulet started before bundles were even a construct in Juju with a spec written before Juju 1.0. Since then, many new comers to the ecosystem have remarked how odd it is to be writing deployment validations at the charm level. Indeed, as years have gone by and new tools have sprung up it's become clear that; having an author try to model all the permutations of a charms deployment and do the physical deploys at that charm level are tedious and incomplete at best.</div><div><br></div><div>With the explosion of layers and improvements to uniting test in charms at that component level, I feel that continuing to create these bespoke "bundles" via amulet in a single charm will not be a robust solution going forward. As we sprint closer to Juju 2.0 we're seeing a higher demand for assurance of working scenarios, and a sharp focus on quality at every level. As such I'd like to propose the following policy changes:</div><div><br></div><div>- All bundles must have tests before promulgation to the store</div><div>- All charms need to have comprehensive tests (unit or amulet)</div><div>- All charms should be included in a bundle</div><div><br></div><div>I'll break down my reasoning and examples in the following sections:</div><div><br></div><div># All bundles must have tests before promulgation to the store</div><div><br></div><div>Writing bundle tests with Amulet is actually a more compelling story today than writing an Amulet test case for a charm. As an example, there's a new ELK stack bundle being produced, here's what the test for that bundle looks like: <a href="https://github.com/juju-solutions/bundle-elk-stack/blob/master/tests/10-test-bundle" target="_blank">https://github.com/juju-solutions/bundle-elk-stack/blob/master/tests/10-test-bundle</a></div><div><br></div><div>This makes a lot of sense because it's asserting that the bundle is working as expected by the Author who put the bundle together. It's also loading the bundle.yaml as the deployment spec meaning as the bundle evolves the tests will make sure they continue to run as expected. Also, this could potentially be used in future smoke tests for charms being updated if a CI process swaps out, say elasticsearch, for a newer version of a charm being reviewed. We can assert that both the unittests in elasticsearch work and it operates properly in an existing real world solution a la the bundle.</div><div><br></div><div>Additional examples:</div><div>- <a href="https://github.com/juju-solutions/bundle-realtime-syslog-analytics/blob/master/tests/01-bundle.py" target="_blank">https://github.com/juju-solutions/bundle-realtime-syslog-analytics/blob/master/tests/01-bundle.py</a></div><div>- <a href="https://github.com/juju-solutions/bundle-apache-core-batch-processing/blob/master/tests/01-bundle.py" target="_blank">https://github.com/juju-solutions/bundle-apache-core-batch-processing/blob/master/tests/01-bundle.py</a></div><div><br></div><div># All charms need to have comprehensive tests (unit or amulet)</div><div><br></div><div>This is just a clarification and more strongly typed policy change that require charms have (preferred) unit tests or, if not applicable, then an Amulet test. Bash doesn't really allow for unittesting, so in those scenarios, Amulet tests would function as a valid testing case.</div><div><br></div><div>There are also some charms which will not make sense as a bundle. One example is the recently promulgated Fiche charm: <a href="http://bazaar.launchpad.net/~charmers/charms/trusty/fiche/trunk/view/head:/tests/10-deploy" target="_blank">http://bazaar.launchpad.net/~charmers/charms/trusty/fiche/trunk/view/head:/tests/10-deploy</a> It's a standalone pastebin, but it's an awesome service that provides deployment validation with an Amulet test. The test stands up the charm, exercises configuration, and validates the service responds in an expected way. For scenarios where a charm does not have a bundle an Amulet test would be required.</div><div><br></div><div>Any charm that currently includes an Amulet test is welcome to continue keeping such a test.</div><div><br></div><div># All charms should be included in a bundle</div><div><br></div><div>This last one is to underscore that charms need to serve a purpose. This policy is written as not an absolute, but instead a strongly worded suggestion as there are always charms that are exceptions to the rules. One such example is the aforementioned Fiche charm which as a bundle would not make as much sense, but is still a purposeful charm.</div><div><br></div><div>That being said, most users coming to consume Juju are looking to solve a problem. Bundles underscore solutions to problems that people can consume, and get started quicker.</div><div><br></div><div>As such, when new applications are charmed a test of "is this application something that serves a clear purpose" having a bundle submitted alongside the charm validates that claim and provides users a way to immediately get started with a solution.</div><div><br></div><div># Conclusion</div><div><br></div><div>These policy changes, once accepted, will be targeted at all charms and bundles in Xenial as well as any new charm submitted after policy acceptance date for trusty, and finally any charm currently under review will be encouraged to adhere to the new policy but won't be required.</div><div><br></div><div># Action items</div><div><br></div><div>I'm seeking feedback on this concept and welcome suggestions for improvements, questions, dissenting opinions, and any other remarks as well as votes from ~charmers and feedback from the community at large.</div><div><br></div><div>Thanks,</div><div>Marco Ceppi</div></div>
<br></div></div><span>--<br>
Juju mailing list<br>
<a href="mailto:Juju@lists.ubuntu.com" target="_blank">Juju@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju</a><br>
<br></span></blockquote></div><br></div>
<br>--<br>
Juju mailing list<br>
<a href="mailto:Juju@lists.ubuntu.com" target="_blank">Juju@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju</a><br>
<br></blockquote></div><br></div></blockquote></div></div>