A test naming policy makes each test communicate the scenario it verifies and the behavior expected from the system. Plain-English names preserve that meaning for programmers and domain experts, while rigid method-scenario-result templates often expose implementation details and impose a cognitive tax. section 3.4
Apply these practical rules:
- Describe the scenario as a domain behavior rather than repeating the method under test. section 3.4
- Write names as if explaining the scenario to a non-programmer familiar with the problem domain. section 3.7
- Separate words with underscores, and accept that parameterized tests may reduce name readability when generalized. section 3.7
Refactoring a delivery test name
Replace IsDeliveryValid_InvalidDate_ReturnsFalse with Delivery_with_past_date_is_invalid. The latter states the observable business behavior without repeating the method name or using unexplained “Returns” phrasing. section 3.4
