Behavior is what software reveals to an external observer through outputs, state changes, or other visible effects. Tests should verify this user-relevant behavior rather than private implementation details, which makes them less fragile. section 8.4
Use behavior as the boundary for deciding what a test should describe and assert:
- Name the unit of work or feature, describe the scenario, and state the expected behavior visible at the exit point. section 9.1 section 9.5
- Avoid asserting private state, calls on stubs, collection order, or exact strings when those details are not required by the behavior. section 8.4
- Treat a need to test a private method as a possible sign that a missing abstraction should become public or move into another class. section 8.4
A behavior-focused test name
test('verifyPassword, with a failing rule, returns error based on rule.reason', () => { ... })
Listing 9.1 Same information, different variations
test('verifyPassword, with a failing rule, returns error based on rule.reason', () => { ... }
describe('verifyPassword', () => {
describe('with a failing rule', () => {
it('returns error based on the rule.reason', () => { ... }
verifyPassword_withFailingRule_returnsErrorBasedonRuleReason()
Compare a single descriptive test name, nested describe structures, and a method-style name expressing the same unit, scenario, and expected behavior. section 9.1
