HTML and CSS Reference
In-Depth Information
Writing tests that can be trusted, are easy to maintain, and clearly state their intent
takes practice. If you have coded along with the examples in Part III,
Real-World
Test-Driven Development in JavaScript,
you should already have some basic training
doing this, and possibly even have started to develop a nose for good tests.
Readability is a key aspect of a good unit test. If a test is hard to read it is likely
to be misunderstood. This can lead to unfortunate modifications of either tests or
production code, causing the quality of both to drop over time. A good test suite
effectively documents the code under test, and provides a simple overview of what
the code can be expected to do and how it can be used.
17.1.1 Name Tests Clearly to Reveal Intent
The name of a test should clearly and unambiguously state what the purpose of the
test is. A good name makes it easier to understand what a test is trying to achieve, thus
it has more value as unit level documentation and it lessens the chance of someone
changing the test without properly understanding what it's supposed to verify. A
good name also shows up in the test runner's report when it fails, pinpointing the
exact source of error.
When working with TDD, the test name is the very first time you put a feature
down in code. Writing the requirement out in words may help us mentally prepare
for the feature we are about to add. If you find it hard to clearly state what the test
is supposed to do, then it is likely you have not properly recognized the goal of the
test, and it is unlikely that jumping straight to writing test code will result in any
kind of quality unit test, or production code for that matter.
17.1.1.1 Focus on Scannability
Good test names make test cases easy to scan. Scanning a test case with well-named
tests should give us a good high-level understanding of what the module being tested
does and how it is expected to behave in response to given input. It can also help
us understand what kinds of cases are not accounted for, which can be useful when
encountering trouble using a library in a specific way.
Although naming is one of those things in which personal preference does have
a play in what is “clear,” I've found the following rules of thumb to be of good help.
JavaScript property identifiers can be arbitrary strings. Use this powerful
feature to name tests with short sentences using spaces, no underscores or
camelCasedTestNames.
•
•
Using the word “should” underpins the test as a behavior specification.
