Part three of a series of posts about automated testing.

Naming things is one of the hard problems of computer science. However, when it comes to tests, here’s a guideline that could help: include both the condition and the expected behaviour in the test name.

Consider this short example, using Test::Class:

sub frobnicate_returns_false : Test {
    ok(!$widget->frobnicate());
}

This might produce the following warning:

# This message might be ambiguous
not ok 1 - frobnicate returns false

But when you see this test error (perhaps six months after writing the test), it is not obvious whether “returns false” is meant to be the error condition or the expected behaviour.

Including the word “should” is often helpful. Compare the previous example with this friendlier message:

# Good message - contains conditions and expected behaviour
not ok 1 - frobnicate with no arguments should return false

And the code to achieve this:

sub frobnicate_with_no_arguments_should_return_false : Test {
    ok(!$widget->frobnicate());
}

Further reading