I'll definitely +1 the need for gc.HasLen ... I've seen a ton of panics in tests if the code starts erroneously returning nil slices. Obviously this is less bad, since the tests still fail, but they're really ugly annoying failures.
And +1000 to making tests that fail before fixing the code (or at least, purposely re-breaking the code if you forget and fix the bug first)... I've caught so many invalid tests that way... it is the only way to prove to yourself that your test actually work correctly both in proving correct behavior, and signalling bad behavior. On Thu, Dec 3, 2015 at 5:24 PM Tim Penhey <tim.pen...@canonical.com> wrote: > Hi folks, > > I came across an interesting bug yesterday and during investigation > found that there was a very comprehensive test that covered the situation. > > The problem is that the asserts were not actually running. > > The asserts were inside a loop where the expectation was that the loop > would run exactly once as a previous call returned an array of items > with one value in it. > > Except it didn't. > > It returned an empty list. > > So, if you see something like this, a simple line like: > > c.Assert(someList, gc.HasLen, 1) > > Is sufficient to have caught this particular issue. > > > Remember a key step when writing tests is to have the test fail first, > then make it pass. > > One trick I use is to assert checks against data I know is wrong. If the > test passes then I know I have other problems. > > Tim > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
