🧪 Testing Strategies

Building confidence in your code through effective testing.

Testing pyramid

        /  E2E  \        Few, slow, expensive
       / Integration \   Some, moderate
      /    Unit Tests   \ Many, fast, cheap

Test types

Type	Scope	Speed	When to use
Unit	Single function/class	ms	Business logic, pure functions
Integration	Multiple components	seconds	API endpoints, DB queries
E2E	Full user flow	seconds-minutes	Critical paths, smoke tests
Contract	API boundaries	ms	Microservices, external APIs
Snapshot	UI output	ms	Component rendering
Performance	Load/response time	varies	Before release, critical paths

Writing good tests

• Arrange, Act, Assert — Setup, execute, verify
• Test behavior, not implementation
• One assertion per test (when practical)
• Use descriptive test names: should_return_404_when_user_not_found
• Tests should be independent — no shared state between tests
• Tests should be deterministic — same result every time

What to test

• Happy path (expected behavior)
• Edge cases (empty input, null, max values)
• Error cases (invalid input, network failure)
• Boundary conditions (first, last, off-by-one)

What NOT to test

• Third-party library internals
• Trivial getters/setters
• Framework boilerplate
• Implementation details that may change

Test doubles

Type	Purpose
Mock	Verify interactions (was this called?)
Stub	Return predetermined data
Spy	Record calls for later assertion
Fake	Simplified working implementation (in-memory DB)

Coverage

• Aim for 80%+ on business logic
• 100% coverage ≠ bug-free code
• Measure coverage to find gaps, not as a target