Unit Tests & Integration Tests

Andrew Wilkins andrew.wilkins at canonical.com
Fri Sep 12 01:38:02 UTC 2014


On Thu, Sep 11, 2014 at 11:29 PM, Matthew Williams <
matthew.williams at canonical.com> wrote:

> Hi Folks,
>
> There seems to be a general push in the direction of having more mocking
> in unit tests. Obviously this is generally a good thing but there is still
> value in having integration tests that test a number of packages together.
> That's the subject of this mail - I'd like to start discussing how we want
> to do this. Some ideas to get the ball rolling:
>
> Having integration tests spread about the package and having environment
> variables that switch on/ off them being run
>
> $ JUJU_INTEGRATION go test ./...
>
> We could make use of build tags:
>
> $ go test -tags integration ./...
>
> We could put all the integration tests in a single package:
>
> $ go test github.com/juju/juju/integrationtests/...
>


Cut and paste from my reply to Ian's "Call to action" email:

-----
I'd like to make a few suggestions regarding moving tests to CI.

- For now, I think we should create a new package tree under
github.com/juju/juju/ci, and move functional tests there. The package name
is unimportant, alternative suggestions wlecome, but the idea is that they
will continue running as unit tests until CI is ready to start running
them. At that point we'd create build constraints on those tests and they'd
only be run if you explicitly enable them.
- The functional tests may test on package boundaries (e.g. for configuring
replica sets), but may not use package internals.
- The functional tests must be runnable on developers' machines, with
minimal prior setup required (like the unit tests now).
-----

So I think we're thinking the same thing. The tests should not be in one
package, but I think having a common root would be good (I think you're
suggesting that, given the "...").

I'd be fine with Roger's suggestion of using -short to disable the
longer-running integration tests (e.g. replicaset). If the tests are short,
then I don't see a compelling reason to disable them in regular runs. They
need to be stable either way.

Cheers,
Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140912/427103c8/attachment.html>


More information about the Juju-dev mailing list