derive-test-name-from-behavior

name	derive-test-name-from-behavior
description	Produce a single test name in "should <observable behavior>" form from a goal statement. Use when starting the red phase of a TDD cycle and you need a precise, testable name.

Derive a test name from a behavior

Given a behavior description, produce one test name that asserts a single observable outcome.

Rules

1. Start with should.
2. Describe the observable outcome, not the implementation. should reject empty username is observable; should call validateUsername is implementation-detail leakage.
3. Be specific about input shape and expected output. should return ValidationError when username is empty beats should validate username.
4. One test = one assertion target. If you find yourself joining clauses with and, split into two tests.

Examples

• Behavior: "username validation"

  • Bad: should validate username
  • Better: should reject empty username
  • Better still: should reject empty username with a ValidationError

• Behavior: "OAuth flow"

  • Bad: should handle OAuth
  • Better: should redirect to provider when no token is present
  • Better still: should redirect to /oauth/authorize with the configured client_id

Reusable outside TDD

Coverage-gap workflows use this when proposing tests for uncovered branches.