Testing Methodologies

The Testing Pyramid

Mike Cohn's concept. It dictates the volume of tests you should have.

1. Unit Tests (Base): 70%. Fast, cheap, precise. Test individual functions.
2. Integration Tests (Middle): 20%. Slower. Test how modules interact (e.g., Service + Database).
3. E2E / UI Tests (Top): 10%. Slow, brittle, expensive. Test the full user journey.

Anti-Pattern: The Ice Cream Cone. Teams with manual QA often have tons of E2E tests and zero unit tests. This is slow and hard to maintain.

---

TDD (Test Driven Development)

The cycle: Red -> Green -> Refactor.

1. Red: Write a failing test for a feature that doesn't exist.
2. Green: Write the minimum code to pass the test.
3. Refactor: Clean up the code while keeping the test passing.

Why? It forces you to design testable code and prevents over-engineering.

---

BDD (Behavior Driven Development)

Uses human-readable language (Gherkin) to define requirements.

• Framework: Cucumber.
• Format:

  Feature: User Login
    Scenario: Successful Login
      Given I am on the login page
      When I enter valid credentials
      Then I should be redirected to the dashboard

• Pros: Aligns Product, QA, and Devs.
• Cons: High maintenance overhead to map text to code.

---

Shift Left

The practice of moving testing earlier in the lifecycle.

• Traditional: Code -> Build -> Deploy -> QA finds bugs.
• Shift Left: Code -> Unit Test -> Static Analysis -> QA finds bugs before merge.
• Cost of Bug: Fixing a bug in Prod costs 100x more than fixing it in Design.