Testing Patterns

What to Test

Always test:

• Happy path (normal inputs → expected output)
• Edge cases (empty, null, undefined, zero, max values)
• Error cases (invalid input, missing data, network failure)
• Boundary values (off-by-one, exactly at limits)
• Security-critical paths (auth, permissions, input validation)

Don't test:

• Implementation details (private methods, internal state)
• Third-party library internals
• Trivial getters/setters with no logic
• CSS styling or pixel-perfect layouts

Mocking Strategy

Rules:

• Mock at the boundary, not deep inside
• Prefer dependency injection over global mocks
• Reset mocks between tests (beforeEach / afterEach)
• Never mock what you're testing

Test Naming

Use descriptive names that explain the scenario:

// Good
"should return 404 when user does not exist"
"should hash password before saving to database"
"should retry failed request up to 3 times"

// Bad
"test1"
"works correctly"
"handles error"

Coverage Targets

• 80% minimum for all code
• 100% required for: auth logic, financial calculations, security-critical code
• Coverage measures lines hit, not correctness. High coverage with weak assertions is useless
• Focus on meaningful assertions, not just line coverage

Common Anti-Patterns

• Testing implementation instead of behavior
• Tests that pass regardless of the implementation
• Shared mutable state between tests (tests must be independent)
• Over-mocking (prefer integration tests when possible)
• Ignoring flaky tests (fix the root cause immediately)
• Testing only the happy path