Be very careful in assumptions in tests

William Reade william.reade at canonical.com
Fri Dec 4 08:58:46 UTC 2015


Indeed, and to expand on all that: test-first or test-last, it's smart to
purposely break your code and make sure that your test *fails* semi-cleanly
(rather than, e.g., deadlocking).

On Fri, Dec 4, 2015 at 3:32 AM, Nate Finch <nate.finch at canonical.com> wrote:

> 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.penhey at 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 at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20151204/ecc060c0/attachment.html>


More information about the Juju-dev mailing list