Testing Skill

When to use this skill

Use when writing tests of any kind: unit, integration, end-to-end, or when designing a testing strategy for a new feature.

Testing Philosophy

Core beliefs

1. •Test behavior, not implementation. Tests should describe what the code does, not how it does it internally. If a refactor breaks your tests, the tests were wrong.
2. •Tests are documentation. A well-written test suite tells you exactly what the system does and what edge cases exist.
3. •Fast feedback > complete coverage. A fast test suite that runs on every change beats a slow, comprehensive suite that nobody runs.
4. •One assertion per test concept. Each test should verify one behavior. If it fails, you know exactly what broke.

Test Pyramid

         ╱  E2E  ╲         Few — slow, expensive, high confidence
        ╱─────────╲
       ╱Integration╲       Some — moderate speed, test component interactions
      ╱─────────────╲
     ╱  Unit Tests   ╲     Many — fast, cheap, test logic in isolation
    ╱─────────────────╲

Unit Tests

Structure: Arrange-Act-Assert (AAA)

// ARRANGE — set up the test data and dependencies
const user = createTestUser({ name: "Alice" })
const service = new UserService(mockRepo)

// ACT — perform the action being tested
const result = service.updateName(user.id, "Bob")

// ASSERT — verify the outcome
expect(result.name).toBe("Bob")

Naming convention

Test names should read like sentences:

✅ "returns empty list when no orders exist"
✅ "throws ValidationError when email is invalid"
✅ "sends notification email after successful signup"

❌ "test1"
❌ "testUpdateUser"
❌ "it works"

What to unit test

• •All business logic in service/ layer
• •Data transformation functions
• •Validation logic
• •Error handling paths
• •Edge cases: empty input, null, boundary values, overflow

What NOT to unit test

• •Framework boilerplate (routing config, middleware registration)
• •Simple getters/setters with no logic
• •Third-party library internals
• •Database queries (save for integration tests)

Integration Tests

What to test

• •Database queries (repo layer with real/test database)
• •API endpoints (HTTP request → response)
• •Component interactions (service A calls service B)
• •External service integrations (with containerized dependencies)

Rules

• •Use a real test database (not mocks) — spin up with Docker or in-memory
• •Reset state between tests — each test starts with a clean slate
• •Seed realistic data — don't test with just one row
• •Test the unhappy paths — what happens when the DB is down, the API returns 500?

End-to-End Tests

What to test

• •Critical user journeys — signup, login, purchase, core workflows
• •Cross-page flows — navigation, multi-step forms, redirects
• •Only test the happy path + most important failure per journey

Rules

• •Keep E2E tests minimal — they're slow and fragile
• •Use stable selectors — data-testid attributes, not CSS classes
• •Wait for elements — never use fixed sleep/delays
• •Isolate test data — each test creates its own data, cleans up after
• •Record failures — capture screenshots/video on test failure

E2E test structure

describe("User signup flow")
  it("creates account with valid details")
    → navigate to signup page
    → fill in form fields
    → submit
    → verify redirect to dashboard
    → verify welcome message displayed

  it("shows error for duplicate email")
    → navigate to signup page
    → fill in form with existing email
    → submit
    → verify error message displayed
    → verify user stays on signup page

Test Data

Rules

• •Never use production data in tests
• •Use factories/builders to create test data — not raw constructors
• •Make test data realistic — use realistic names, emails, amounts
• •Randomize where appropriate — catch assumptions with random data
• •Clean up — delete test data after each test run

Test data pattern

// Factory pattern — create test data with sensible defaults
function createTestUser(overrides = {}) {
  return {
    id: generateId(),
    name: "Test User",
    email: "test@example.com",
    role: "user",
    ...overrides  // allow overriding any field
  }
}

// Usage
const admin = createTestUser({ role: "admin" })
const unverified = createTestUser({ isVerified: false })

Mocking

When to mock

• •External services (APIs, payment providers, email)
• •Time-dependent logic (use a clock mock)
• •Randomness (seed the random generator)
• •Expensive operations (file I/O, network calls)

When NOT to mock

• •Your own code (test the real implementation)
• •The database (use a test database instead)
• •Simple utility functions

Mocking rules

• •Mock at the boundary — mock the external interface, not internal details
• •Verify mock interactions sparingly — prefer asserting on outputs over inputs
• •Keep mocks simple — if your mock is complex, the design might need rethinking

Common Anti-Patterns

Coverage

• •Don't chase 100% coverage — it's expensive and gives false confidence
• •Target: 80%+ for service/business logic, 60%+ overall
• •Coverage is a floor, not a ceiling — meaningful tests matter more than the number
• •Uncovered code should be intentional — add a comment if you deliberately skip testing something

PR Checklist for Tests

• • New logic has corresponding unit tests
• • Tests follow AAA structure (Arrange-Act-Assert)
• • Test names read like sentences
• • Edge cases covered (empty, null, boundary, error)
• • No sleep/fixed delays — uses proper async waiting
• • No shared mutable state between tests
• • Test data uses factories, not raw constructors
• • Mocks are at the boundary only
• • All tests pass locally (./scripts/dev/test)