test-namerlisted

# 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: ``` IsDeliveryValid_InvalidDate_ReturnsFalse -- rigid, cryptic Delivery_with_invalid_date_should_be_invalid -- plain English (good start) Delivery_with_past_date_should_be_invalid -- more specific Delivery_with_past_date_is_invalid -- fact, not wish Delivery_with_a_past_date_is_invalid -- natural grammar (final) ``` ### Exception: Utility Code For utility/helper code without business logic, referencing the method name is acceptable since the behavior doesn't mean anything to busine