A test name is the reader’s fast explanation of what a test checks. A useful name states three things: the unit under test, the scenario or inputs, and the expected behavior or exit point. This USE pattern—unit, scenario, expectation—makes a failed test informative even when the runner shows only its name. section 2.5.3 section 9.1
Include information that answers the reader’s immediate questions:
- Name the entry point or feature under test, such as verifyPassword. section 9.1
- State the scenario, including the relevant input or condition, such as a failing rule. section 2.5.3
- State the expected observable behavior, such as returning an error based on rule.reason. section 9.1
Name one concern clearly
`verifyPassword, given a failing rule, returns errors` tells a reader what runs, under which condition, and what should happen. The same information can be split across nested `describe` and `it` labels, as long as all three parts remain nearby. Names that omit the unit, scenario, or expectation force readers to inspect test code. section 2.5.3 section 9.1
A vague name often signals that a test checks too many concerns. Separate tests for separate exit points keep names focused and preserve diagnostic information: when one assertion fails, later assertions may not run. Multiple assertions can still fit one test when they verify the same exit point. section 7.4.4 section 5.6.4
Listing 2.5 Naming a test with USE
test('verifyPassword, given a failing rule, returns errors', () => {
const fakeRule = input => ({ passed: false, reason: 'fake reason' });
const errors = verifyPassword('any value', [fakeRule]);
expect(errors[0]).toContain('fake reason');
});
This small test shows a USE-style name alongside the scenario setup and assertion it summarizes. section 2.5.3
