Test Type Decision Tree

Visual guide to help you choose the right test types for your situation.


Quick Decision Tree

START: What do you need to test?
│
├─→ New functionality?
│   │
│   ├─→ Before writing code? ──→ TDD: Generate UNIT tests first
│   │                             Framework recommendation based on language
│   │
│   └─→ After writing code? ──→ Do you need multiple test types?
│       │
│       ├─→ Yes ──→ Use COMPREHENSIVE template (unit + integration + E2E)
│       │
│       └─→ No ──→ What's most important?
│           │
│           ├─→ Business logic correctness ──→ UNIT tests
│           ├─→ Service interactions ──→ INTEGRATION tests
│           └─→ User experience ──→ E2E tests
│
├─→ Existing code?
│   │
│   ├─→ Has specifications? ──→ Do tests exist?
│   │   │
│   │   ├─→ Yes ──→ GAP ANALYSIS template
│   │   │           (find missing coverage)
│   │   │
│   │   └─→ No ──→ COMPREHENSIVE template
│   │               (full coverage from scratch)
│   │
│   └─→ No specifications (legacy)? ──→ CHARACTERIZATION tests
│       │                                (document current behavior)
│       │
│       └─→ Then refactor safely
│
├─→ API endpoints?
│   │
│   ├─→ Testing contracts? ──→ API CONTRACT tests
│   │                          (request/response schemas)
│   │
│   ├─→ Testing behavior? ──→ INTEGRATION tests
│   │                         (business logic + DB)
│   │
│   └─→ Testing from user perspective? ──→ E2E API tests
│                                          (complete workflows)
│
├─→ Before deployment?
│   │
│   ├─→ Need fast validation? ──→ SMOKE tests
│   │                             (< 2 min, critical paths only)
│   │
│   ├─→ Need comprehensive check? ──→ REGRESSION tests
│   │                                 (all existing functionality)
│   │
│   └─→ Need deployment approval? ──→ PRE-DEPLOYMENT validation
│                                     (migrations, config, perf)
│
├─→ After deployment?
│   │
│   └─→ Verify deployment success? ──→ SMOKE tests
│                                      (production health checks)
│
├─→ Found a bug?
│   │
│   └─→ Write test that reproduces it ──→ UNIT or INTEGRATION test
│       └─→ Fix bug
│           └─→ Test passes ──→ Add to REGRESSION suite
│
├─→ Refactoring code?
│   │
│   └─→ Need safety net? ──→ CHARACTERIZATION tests first
│       │                    (document current behavior)
│       │
│       └─→ Refactor
│           └─→ Tests still pass? ──→ Safe refactoring ✓
│
├─→ Performance concerns?
│   │
│   ├─→ Expected load? ──→ LOAD tests
│   ├─→ Beyond capacity? ──→ STRESS tests
│   ├─→ Sudden spikes? ──→ SPIKE tests
│   └─→ Extended duration? ──→ ENDURANCE tests
│
├─→ Security concerns?
│   │
│   ├─→ Authentication/Authorization? ──→ SECURITY tests (auth focus)
│   ├─→ Input validation? ──→ SECURITY tests (injection focus)
│   ├─→ Data protection? ──→ SECURITY tests (PII/encryption focus)
│   └─→ All of the above? ──→ COMPREHENSIVE SECURITY suite
│
└─→ Not sure? ──→ Use EXPLORATORY template
                  (Claude will analyze and recommend)

Detailed Decision Paths

Path 1: New Feature Development

New Feature → Choose your approach:

┌─────────────────────────────────────────────────────────────┐
│ TDD (Test-Driven Development)                                │
│                                                               │
│ When to use:                                                  │
│ • Requirements are clear                                      │
│ • You want tests to drive design                             │
│ • Building greenfield features                               │
│                                                               │
│ Steps:                                                        │
│ 1. Generate failing unit tests (RED)                         │
│ 2. Implement code to pass tests (GREEN)                      │
│ 3. Refactor                                                   │
│ 4. Generate more tests for edge cases                        │
│                                                               │
│ Template: Template 5 (TDD)                                    │
└─────────────────────────────────────────────────────────────┘

or

┌─────────────────────────────────────────────────────────────┐
│ Test-After (Traditional)                                      │
│                                                               │
│ When to use:                                                  │
│ • Prototyping or exploring solutions                          │
│ • Requirements are unclear                                    │
│ • Quick iterations needed                                     │
│                                                               │
│ Steps:                                                        │
│ 1. Implement feature                                          │
│ 2. Generate comprehensive tests                               │
│ 3. Run tests and fix issues                                   │
│ 4. Add to regression suite                                    │
│                                                               │
│ Template: Template 6 (Unit Tests for New Code)               │
└─────────────────────────────────────────────────────────────┘

Then add:
• Integration tests (if dependencies)
• E2E tests (if user-facing)
• Performance tests (if critical path)

Path 2: Testing Existing Code

Existing Code → Has documentation/specs?

YES → Tests exist?
      │
      ├→ YES → Coverage adequate?
      │        │
      │        ├→ NO → Use Gap Analysis Template (4 or 12)
      │        │       • Identify untested requirements
      │        │       • Generate missing tests
      │        │       • Prioritize by risk
      │        │
      │        └→ YES → Quality good?
      │                 │
      │                 ├→ NO → Use Quality Audit Template (13)
      │                 │       • Find brittle/flaky tests
      │                 │       • Refactor poor tests
      │                 │       • Improve maintainability
      │                 │
      │                 └→ YES → You're done! ✓
      │
      └→ NO → Use Comprehensive Template (1)
              • Generate full test suite
              • Cover all requirements
              • Include edge cases

NO (legacy code) → Use Characterization Tests Template (7)
                   • Document CURRENT behavior
                   • Don't assume intended behavior
                   • Test side effects
                   • Create safety net

                   Then:
                   • Refactor safely
                   • Update tests to reflect new behavior
                   • Add proper unit/integration tests

Path 3: API Testing

API Endpoints → What do you need?

┌──────────────────────────────────────────┐
│ CONTRACT Testing                          │
│                                           │
│ Validates: Request/response schemas      │
│ Use when: API is shared with consumers   │
│ Focus: Data contracts, not behavior      │
│                                           │
│ Tests:                                    │
│ • Schema validation                       │
│ • Required fields                         │
│ • Data types                              │
│ • Enum values                             │
│                                           │
│ Template: Template 9 (API Contract)      │
└──────────────────────────────────────────┘

+

┌──────────────────────────────────────────┐
│ INTEGRATION Testing                       │
│                                           │
│ Validates: Business logic + DB + auth    │
│ Use when: Testing your own API           │
│ Focus: Behavior and correctness          │
│                                           │
│ Tests:                                    │
│ • CRUD operations                         │
│ • Business rules                          │
│ • Authentication                          │
│ • Authorization                           │
│ • Error handling                          │
│                                           │
│ Template: Template 9 (API Contract)      │
└──────────────────────────────────────────┘

+

┌──────────────────────────────────────────┐
│ E2E API Testing                           │
│                                           │
│ Validates: Complete workflows             │
│ Use when: Multi-step processes            │
│ Focus: User/system workflows              │
│                                           │
│ Tests:                                    │
│ • Multi-endpoint flows                    │
│ • State transitions                       │
│ • Real-world scenarios                    │
│                                           │
│ Template: Template 11 (E2E User Journey) │
└──────────────────────────────────────────┘

Recommendation:
• Start with contract tests (fast, catches schema issues)
• Add integration tests (business logic)
• Add E2E for critical workflows (slow but comprehensive)

Path 4: Pre-Release Testing

Before Release → What's your timeline?

FAST (< 1 hour)
│
├→ Critical paths only → SMOKE tests
│  • 10-20 tests, < 2 min total
│  • Happy paths for core features
│  • Quick validation before release
│
│  Template: Template 15 (Smoke Tests)

MEDIUM (1-4 hours)
│
├→ Core functionality → REGRESSION tests (focused)
│  • 50-100 tests, < 30 min total
│  • Previously fixed bugs
│  • High-risk areas
│  • Integration points
│
│  Template: Template 2 (Regression - focused)

THOROUGH (1+ day)
│
└→ Everything → COMPREHENSIVE REGRESSION
   • 200+ tests, 1-2 hours total
   • All functionality
   • All edge cases
   • Performance tests
   • Security tests

   Template: Template 2 (Regression - comprehensive)

Plus:
• Manual exploratory testing
• Staging environment validation
• Performance baseline checks

Path 5: Found a Bug