home / skills / vudovn / antigravity-kit / testing-patterns

testing-patterns skill

/.agent/skills/testing-patterns

This skill helps you apply testing patterns and principles to unit, integration, and mocking strategies, improving reliability and maintainability of test

npx playbooks add skill vudovn/antigravity-kit --skill testing-patterns

Review the files below or copy the command above to add this skill to your agents.

Files (2)
SKILL.md
3.4 KB
---
name: testing-patterns
description: Testing patterns and principles. Unit, integration, mocking strategies.
allowed-tools: Read, Write, Edit, Glob, Grep, Bash
---

# Testing Patterns

> Principles for reliable test suites.

---

## 1. Testing Pyramid

```
        /\          E2E (Few)
       /  \         Critical flows
      /----\
     /      \       Integration (Some)
    /--------\      API, DB queries
   /          \
  /------------\    Unit (Many)
                    Functions, classes
```

---

## 2. AAA Pattern

| Step | Purpose |
|------|---------|
| **Arrange** | Set up test data |
| **Act** | Execute code under test |
| **Assert** | Verify outcome |

---

## 3. Test Type Selection

### When to Use Each

| Type | Best For | Speed |
|------|----------|-------|
| **Unit** | Pure functions, logic | Fast (<50ms) |
| **Integration** | API, DB, services | Medium |
| **E2E** | Critical user flows | Slow |

---

## 4. Unit Test Principles

### Good Unit Tests

| Principle | Meaning |
|-----------|---------|
| Fast | < 100ms each |
| Isolated | No external deps |
| Repeatable | Same result always |
| Self-checking | No manual verification |
| Timely | Written with code |

### What to Unit Test

| Test | Don't Test |
|------|------------|
| Business logic | Framework code |
| Edge cases | Third-party libs |
| Error handling | Simple getters |

---

## 5. Integration Test Principles

### What to Test

| Area | Focus |
|------|-------|
| API endpoints | Request/response |
| Database | Queries, transactions |
| External services | Contracts |

### Setup/Teardown

| Phase | Action |
|-------|--------|
| Before All | Connect resources |
| Before Each | Reset state |
| After Each | Clean up |
| After All | Disconnect |

---

## 6. Mocking Principles

### When to Mock

| Mock | Don't Mock |
|------|------------|
| External APIs | The code under test |
| Database (unit) | Simple dependencies |
| Time/random | Pure functions |
| Network | In-memory stores |

### Mock Types

| Type | Use |
|------|-----|
| Stub | Return fixed values |
| Spy | Track calls |
| Mock | Set expectations |
| Fake | Simplified implementation |

---

## 7. Test Organization

### Naming

| Pattern | Example |
|---------|---------|
| Should behavior | "should return error when..." |
| When condition | "when user not found..." |
| Given-when-then | "given X, when Y, then Z" |

### Grouping

| Level | Use |
|-------|-----|
| describe | Group related tests |
| it/test | Individual case |
| beforeEach | Common setup |

---

## 8. Test Data

### Strategies

| Approach | Use |
|----------|-----|
| Factories | Generate test data |
| Fixtures | Predefined datasets |
| Builders | Fluent object creation |

### Principles

- Use realistic data
- Randomize non-essential values (faker)
- Share common fixtures
- Keep data minimal

---

## 9. Best Practices

| Practice | Why |
|----------|-----|
| One assert per test | Clear failure reason |
| Independent tests | No order dependency |
| Fast tests | Run frequently |
| Descriptive names | Self-documenting |
| Clean up | Avoid side effects |

---

## 10. Anti-Patterns

| ❌ Don't | ✅ Do |
|----------|-------|
| Test implementation | Test behavior |
| Duplicate test code | Use factories |
| Complex test setup | Simplify or split |
| Ignore flaky tests | Fix root cause |
| Skip cleanup | Reset state |

---

> **Remember:** Tests are documentation. If someone can't understand what the code does from the tests, rewrite them.

Overview

This skill describes practical testing patterns and principles for TypeScript projects, covering unit, integration, and end-to-end approaches. It focuses on reliable, maintainable test suites with concrete strategies for mocking, test organization, and test data management. The content emphasizes speed, isolation, and readable tests that serve as documentation.

How this skill works

The skill outlines the testing pyramid to guide test type distribution and applies the Arrange-Act-Assert pattern to structure cases. It explains selection criteria for unit, integration, and E2E tests and provides concrete mocking types (stub, spy, mock, fake) and when to use them. It also prescribes setup/teardown for integration tests, data generation strategies, and naming/grouping conventions to keep suites fast and deterministic.

When to use it

  • Write unit tests for pure functions, business logic, and edge cases to keep them fast and isolated.
  • Use integration tests for API endpoints, database queries, and service contracts that require multiple components.
  • Reserve E2E tests for critical user flows and cross-system behavior where user-facing correctness matters most.
  • Mock external APIs, network calls, time, or randomness during unit tests to remove flakiness.
  • Employ factories, fixtures, or builders when you need repeatable realistic test data across suites.

Best practices

  • Follow Arrange-Act-Assert and keep tests self-checking and repeatable with no manual steps.
  • Aim for fast tests (<100ms for unit) and independent cases with one clear assertion per test when practical.
  • Name tests descriptively using should/when or given-when-then patterns and group related cases with describe blocks.
  • Use setup/teardown hooks (beforeAll, beforeEach, afterEach, afterAll) for resource management and state reset.
  • Prefer behavior testing over implementation testing; replace duplicated setup with factories or helpers.

Example use cases

  • Unit test a business validation function with stubs for time and random inputs.
  • Integration test an API route against a temporary test database with beforeEach state reset.
  • E2E test a checkout flow to verify critical user journeys across frontend and backend.
  • Replace fragile external HTTP calls with fakes during unit testing and validate contract in integration tests.
  • Use builders to produce minimal, realistic domain objects for complex test scenarios.

FAQ

How many unit tests should I write compared to integration or E2E?

Follow the testing pyramid: many unit tests, some integration tests, and few E2E tests focused on critical flows.

When should I mock the database?

Mock the database for unit tests to keep them isolated; use a real or test database for integration tests to validate queries and transactions.

What if a test is flaky?

Investigate root cause: isolate external dependencies, add proper setup/teardown, replace unstable mocks with controlled fakes, or move the scenario to a more appropriate test type.