Writing Good Unit Tests - Test-Driven JavaScript Development - page 463

• Keep names as short as possible without sacrificing clarity.

• Group-related tests in separate test cases and indicate the relation in the test

case name, thus avoiding the same prefix in a large number of tests.

• Never state what code is expected to do using the word “and;” doing so

indicates the test is not specific enough, i.e., it is likely trying to test more than
one aspect of the target method.

Focus on the what and why , not the how .

•

17.1.1.2 Breaking Free of Technical Limitations

All of the tests in Part III, Real-World Test-Driven Development in JavaScript, were
written using libraries that consider any method whose name starts with “test” to
be a test. This leaves room for adding other properties on the test case that are not
run as tests. In the interest of using libraries without modification, we have rolled
with this, ending up with a bunch of tests with names starting with “test should,”
which is a bit of a smell.
Because we can easily add helper functions in a closure surrounding the test
case, there really is no need for the test case to reserve space for helper methods
(i.e., function properties whose names do not start with the obligatory “test”).
By considering any function-valued property a test, test cases could allow more
flexibility in the naming of tests. Luckily, wrapping, e.g., JsTestDriver's TestCase
function to do just that is simple. Listing 17.1 shows an enhanced test case function.
It works just like the original, only all functions except setUp and tearDown are
considered tests.
Listing 17.1 Enhancing JsTestDriver's test case function

function testCaseEnhanced(name, tests) {
var testMethods = {};
var property;

for (var testName in tests) {
property = tests[testName];

if (typeof property == "function" &&
!/^(setUp | tearDown) $ /.test(testName)) {
testName = "test " + testName;

}

testMethods[testName] = property;

}

return TestCase(name, testMethods);

}