Testing Tdd

A unit test verifies the behavior of a single, isolated piece of code (e.g., a function or method). Key characteristics:Tests one logical unit in isolationDependencies are mocked or stubbedRuns fast (milliseconds)Deterministic and repeatableExample in Jest:
test('add returns sum', () => { expect(add(2, 3)).toBe(5); });

An integration test verifies that multiple components work correctly together. Unlike unit tests, it exercises real interactions:Tests communication between modules, services, or layersMay use real databases, APIs, or file systemsSlower than unit tests but catches interface bugsExample: testing a controller that queries a real database

An E2E test simulates real user workflows through the entire application stack. It validates the system from the user's perspective:Uses tools like Playwright, Cypress, or SeleniumTests full user journeys (login → action → logout)Slowest and most brittle test typeCatches integration issues across the whole system

The Test Pyramid is a testing strategy that recommends:Base (most): Unit tests — fast, cheap, numerousMiddle: Integration tests — moderate speed and countTop (fewest): E2E tests — slow, expensive, fewThe idea is to have many small, fast tests and fewer large, slow ones. This gives fast feedback while still covering the full stack. Coined by Mike Cohn.

TDD is a development practice where you write tests before writing production code. The cycle is:Red: Write a failing test for the desired behaviorGreen: Write the minimum code to make the test passRefactor: Clean up the code while keeping tests greenBenefits: better design, fewer bugs, living documentation, and confidence in refactoring.

Red-Green-Refactor is the TDD cycle:Red: Write a test that fails (no implementation yet)Green: Write just enough code to pass the testRefactor: Improve code structure without changing behaviorThe key rule: never write production code without a failing test first. Each iteration should be small (minutes, not hours).

Mocking replaces a real dependency with a controlled fake object that can:Return predefined valuesTrack how it was called (arguments, call count)Verify interactions between the system under test and its dependenciesExample in Jest:
const mockFn = jest.fn().mockReturnValue(42);
Mocks are useful for isolating units and testing behavior without side effects.

Stub: Provides canned answers to calls. Used for state verification — you check the result.
Mock: Pre-programmed with expectations. Used for behavior verification — you check that specific methods were called.

Example:Stub: getUser() always returns { name: "Alice" }Mock: Asserts getUser() was called exactly once with ID 5

A spy wraps a real function, allowing it to execute normally while also recording information about its calls:Tracks call count, arguments, return valuesDoes not replace the implementation (unlike mocks/stubs)Useful for verifying side effects without changing behaviorExample in Jest:
const spy = jest.spyOn(obj, 'method');
expect(spy).toHaveBeenCalledWith('arg');

Test doubles replace real dependencies in tests:Dummy: Passed around but never used (fills parameter lists)Stub: Provides canned responses to callsSpy: Records calls while executing real logicMock: Pre-programmed with expectations to verify behaviorFake: Working implementation with shortcuts (e.g., in-memory database)Term coined by Gerard Meszaros in xUnit Test Patterns.

BDD extends TDD by writing tests in natural language that describe behavior from a user's perspective:Uses ubiquitous language shared by devs, QA, and stakeholdersTests are structured as scenarios with Given-When-ThenTools: Cucumber, SpecFlow, BehaveBDD focuses on what the system does, not how it's implemented.

Gherkin is a structured language for writing BDD scenarios:
Feature: User login
  Scenario: Valid credentials
    Given a registered user
    When they enter valid credentials
    Then they should see the dashboard

Keywords: Feature, Scenario, Given, When, Then, And, But. It's human-readable and executable.