Test Design Skill

A structured approach to designing tests that give confidence without excessive maintenance burden.

Core Philosophy

Test behavior, not implementation. Tests that couple to internal implementation details become fragile and refactor-resistant. Aim to test what the code does, not how it does it.

The best test is the one that fails when something breaks, and passes when everything works. Perfect coverage means nothing if tests don't catch real bugs.

Testing Pyramid

CODEBLOCK0

Unit tests form the base — fast, isolated, cover individual functions.
Integration tests verify components work together.
E2E tests validate complete user journeys.

Test Case Design

Arrange-Act-Assert (AAA) Pattern

CODEBLOCK1

Given-When-Then (GWT) Pattern

CODEBLOCK2

Test Categories

🔴 Happy Path Tests

• - Verify the main success scenario works
• At least one per feature/function

🟡 Edge Case Tests

• - Boundary values (0, -1, max integer)
• Empty/null inputs
• Rare but possible conditions

🟡 Error Case Tests

• - Invalid inputs
• Missing dependencies
• Permission denied scenarios

🟢 Edge/Extreme Cases

• - Very large inputs
• Very small inputs
• Unicode/special characters
• Concurrent access

Test Doubles (Mocks/Stubs/Fakes)

Type	Purpose	Use When
Dummy	Fill parameter lists	Never actually used
Stub

Provide predetermined responses | Test requires specific data | | Spy | Record how something was called | Verify interactions | | Mock | Pre-programmed expectations | Verify behavior + interactions | | Fake | Working implementation (simplified) | Real impl too slow/complex |

Rule: Prefer real objects over mocks when practical. Mocks hide integration problems.

Test Naming Convention

CODEBLOCK3

Examples:

• - INLINECODE0
• INLINECODE1
• INLINECODE2

Coverage Targets

Layer	Target	Purpose
Unit	70-80%	Core business logic
Integration

40-60% | Key flows work together | | E2E | Critical paths only | User journeys |

Note: Coverage is a guide, not a goal. 100% coverage with shallow tests is worse than 70% with meaningful assertions.

Test Execution

Unit Tests

Run frequently during development (every save). CODEBLOCK4

Integration Tests

Run before PR, after unit tests pass. CODEBLOCK5

E2E Tests

Run on CI against deployed environment. CODEBLOCK6

Test Data Management

Strategies

1. 1. Factories/Fixtures — Create test data on demand
2. Seeded Data — Deterministic test datasets
3. Randomized Data — Fuzz testing with random inputs
4. Snapshot Testing — Verify serializable outputs

Best Practices

• - Tests should be independent (no shared state)
• Each test should clean up after itself
• Use meaningful data, not magic values
• Avoid test interdependencies

File Structure

CODEBLOCK7