The Art of Naming Tests

A test name is the first clue to what's being verified. A bad name hides intent. A good name tells the story.

Why Test Names Matter

  • Communication: Test names are documentation. They explain behavior to future developers.
  • Debugging: When a test fails in CI, the name should instantly tell you what broke.
  • Maintenance: Clear names prevent duplicated tests and make it easier to refactor safely.

Patterns for Good Names

1. Describe Behavior, Not Implementation

✅ registers_user_with_valid_email
❌ calls_Save_on_UserRepo

2. Use Given/When/Then Style

given_invalid_password_when_registering_then_error_returned

Reads like a mini-spec.

3. Prefer Specific over Vague

✅ rejects_login_with_expired_token
❌ testLogin

4. Keep It Concise but Clear

  • Long enough to be descriptive, short enough to read at a glance.
  • Avoid novel-length test names.

5. Consistency is Key

Pick a pattern (camelCase, snake_case, sentence-style) and stick to it across the suite.

Common Anti-Patterns

test1, test2, test_final→ Useless.
Overloaded Names: testUser (what about the user?).
Copy-Paste Failures: Two tests with the same name but different logic.

Pro Tips

  • Imagine the test name as the headline of a bug report. Would it make sense to someone skimming logs?
  • Don't fear longer names if they add clarity. rejects_login_with_expired_token beats testLogin every time.

Golden Rule

👉 A test name should explain the behavior under test so clearly that you don't need to read the code to understand it.