Test Namer

Write tests that describe behavior in plain English, not implementation details. Based on Vladimir Khorikov's testing principles.

Naming Guidelines

Rules

1. No rigid naming policy — never use [MethodUnderTest]_[Scenario]_[ExpectedResult] or similar templates
2. Describe behavior to a non-programmer familiar with the problem domain — a domain expert should understand the test name
3. Separate words with underscores in function/method names (not needed in string-based test names like JS/TS)
4. Do not include the SUT's method name in the test name — test behavior, not a method
5. Use plain facts, not wishes — write is_invalid, not should_be_invalid
6. Use basic English grammar — articles (a, the) improve readability
7. Be specific — Delivery_with_a_past_date_is_invalid beats Delivery_with_invalid_date_is_invalid

Naming Progression Example

Starting from a rigid convention — progressively improve: