<p dir="ltr">I would like to propose that we *tag* tests as small, medium, or large. </p>
<p dir="ltr">Small tests are measured in millisecionds, medium are measured in seconds up to a minute, and large are measured in minutes or hours</p>
<p dir="ltr">We should run small tests locally, all the time.   Medium tests should gate commits.   Large tests should be run on a periodic basis, hourly, daily our whatever is required to catch errors on a regular basis. </p>

<p dir="ltr">I think we have mechanisms to run all three sets of tests.   The CI folks have stuff to create environments and /do things/, we have local test running, and we have both commit level testing, and periodic CI tests.  </p>

<p dir="ltr">What we don't yet have is clear definition on where various tests belong, and how to add them.  Nor do we have a clear way to mark tests in the unit test suite as "medium" so that developers can have a very fast set of tests to run, and we don't have so much backpressure on adding "more expensive" tests. <br>
</p>
<div class="gmail_quot<blockquote class=" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We've been working on adding a backup method to the API client.  One<br>
test I wanted to add was a functional test that did no patching<br>
anywhere.  Such an end-to-end test would give us more confidence in<br>
the API method.  We currently have something like that for<br>
backup/restore, but only as a CI test running on jenkins.<br>
<br>
As I understand it, there are two roadblocks to getting such a<br>
functional test in our test suite:<br>
<br>
1. such a test would drastically slow down our other tests;<br>
2. we don't have an easy way to set up a clean full environment<br>
against which to run the test,<br>
<br>
Solving the first should be as simple as only running the test when<br>
some env variable is set (e.g. JUJU_TESTING_INCLUDE_SLOW).<br>
<br>
However, solving the second roadblock isn't so trivial.  Ideally the<br>
test would create an LXC into which it would bootstrap.  Then the test<br>
would set up the environment however it needed before running the API<br>
client method against that environment.  I imagine that this could be<br>
addressed with something similar to a local provider but where the<br>
master is also in an LXC (and the kinks with that are worked out).<br>
>From what I understand there has been some discussion on this already.<br>
How hard would it be to do this?<br>
<br>
While my interest is specifically for backup/restore, I imagine that<br>
other API client methods (and perhaps other parts of juju) would<br>
benefit from the above functionality.<br>
<br>
Thoughts?<br>
<br>
-eric<br>
<br>
--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
</div>