Unit Tests & Integration Tests

[Gustavo Niemeyer]

On Fri, Sep 12, 2014 at 12:00 PM, Mark Ramm-Christensen
(Canonical.com) <mark.ramm-christensen at canonical.com> wrote:
> I think the two issues ARE related because a bias against mocks, and a
> failure to separate out functional tests, in a large project leads to a test
> suite that has lots of large slow tests, and which developers can't easily
> run many, many, many times a day.

There are test doubles in the code base of juju since pretty much the
start (dummy provider?). If you have large slow tests, this should be
fixed, but that's orthogonal to having these or not.

Then, having a bias against test doubles everywhere is a good thing.
Ideally the implementation itself should be properly factored out so
that you don't need the doubles in the first place. Michael Foord
already described this in a better way.

If you want to have a rule "Tests are slow, you should X", the best X
is "think about what you are doing", rather than "use test doubles".

> By allowing explicit ways to write larger functional tests as well as small
> (unitish) tests you get to let the two kinds of tests be what they need to
> be, without trying to have one test suite serve both purposes.  And the
> creation of a "place" for those larger tests was just as much a part of the
> point of this thread, as Roger's comments on mocking.

If by "functional test" you mean "test that is necessarily slow",
there should not be _a_ place for them, because you may want those in
multiple places in the code base, to test local logic that is
necessarily expensive. Roger covered that by suggesting a flag that is
run when you want to skip those. This is a common technique in other
projects, and tends to work well.


gustavo @ http://niemeyer.net