Testing & Quality on Software Engineering Learning Paths

Testing Philosophy

Mon, 01 Jan 0001 00:00:00 +0000

Testing Philosophy#

Before writing a single test, you need to understand why testing matters, what to test, and how much testing is enough. This section establishes the mental models that guide every testing decision you’ll make.

Why Test?#

Testing exists to answer one question: does this software do what it should?

But the deeper motivations are:

Motivation	What It Means
Confidence in change	Refactor, upgrade, or extend without fear of breaking existing behaviour
Documentation	Tests describe what the system actually does, not what someone intended
Design feedback	Hard-to-test code is often poorly designed — tests push toward better architecture
Defect prevention	Catching bugs in development costs 10–100× less than in production
Speed	Automated checks run in seconds; manual verification takes minutes to hours

The Cost of Bugs Over Time#

The later a defect is found, the more expensive it is to fix:

Unit Testing

Mon, 01 Jan 0001 00:00:00 +0000

Unit Testing#

Unit tests verify the smallest pieces of your code in isolation. They’re fast, focused, and form the foundation of any test suite. This section covers patterns and practices for writing effective unit tests.

The AAA Pattern#

Every well-structured unit test follows three phases:

graph LR
 A[Arrange<br/>Set up inputs & dependencies] --> B[Act<br/>Execute the code under test]
 B --> C[Assert<br/>Verify the outcome]

Python Example#

def test_calculate_total_with_discount():
 # Arrange
 items = [
 {"name": "Widget", "price": 25.00, "quantity": 2},
 {"name": "Gadget", "price": 15.00, "quantity": 1},
 ]
 discount_percentage = 10

 # Act
 total = calculate_total(items, discount=discount_percentage)

 # Assert
 assert total == 58.50 # (50 + 15) * 0.90

JavaScript Example#

test('calculate total applies discount correctly', () => {
 // Arrange
 const items = [
 { name: 'Widget', price: 25.00, quantity: 2 },
 { name: 'Gadget', price: 15.00, quantity: 1 },
 ];
 const discount = 10;

 // Act
 const total = calculateTotal(items, { discount });

 // Assert
 expect(total).toBe(58.50);
});

Rules for AAA#

Phase	Guidelines
Arrange	Set up only what’s needed for this test. Use helpers/factories for complex setup.
Act	Exactly one action. If you need multiple actions, it’s probably multiple tests.
Assert	Check one logical concept (may be multiple `assert` statements for one concept).

Test Naming#

Good test names describe the scenario and expected outcome:

Mocking & Test Doubles

Mon, 01 Jan 0001 00:00:00 +0000

Mocking & Test Doubles#

When code depends on external systems — databases, APIs, file systems, or clocks — you need strategies to test in isolation. Test doubles replace real dependencies with controlled substitutes. This section covers types of doubles, when to use them, and how to avoid the over-mocking trap.

Types of Test Doubles#

graph TB
 TD[Test Doubles] --> DUMMY[Dummy<br/>Fills a parameter slot]
 TD --> STUB[Stub<br/>Returns canned data]
 TD --> SPY[Spy<br/>Records interactions]
 TD --> MOCK[Mock<br/>Verifies expectations]
 TD --> FAKE[Fake<br/>Working simplified implementation]

Comparison Table#

Double	Purpose	Verifies Behaviour?	Has Logic?	Example
Dummy	Satisfies a type signature, never actually used	No	No	A null logger passed to a constructor
Stub	Returns pre-configured responses	No	Minimal	`get_user()` always returns `{"id": 1, "name": "Alice"}`
Spy	Records calls for later verification	Yes (after the fact)	No	Records that `send_email` was called with specific args
Mock	Expects specific calls — fails if not met	Yes (built-in)	No	Expects `repository.save(order)` to be called exactly once
Fake	Simplified but functional implementation	No	Yes	In-memory database, local file system

When to Use Each#

Situation	Best Double
Dependency is irrelevant to this test	Dummy
Need to control what dependency returns	Stub
Need to verify how something was called (args, count)	Spy or Mock
Need a working substitute with real behaviour	Fake
Need to prevent real side effects (emails, charges)	Stub or Fake

Practical Examples#

Stubs — Controlling Return Values#

from unittest.mock import patch

def get_weather_message(city: str) -> str:
 """Fetches weather and formats a message."""
 data = weather_api.get_current(city) # External call
 return f"{city}: {data['temp']}°C, {data['condition']}"

@patch("src.weather.weather_api.get_current")
def test_weather_message_formatting(mock_api):
 # Stub: control the return value
 mock_api.return_value = {"temp": 22, "condition": "sunny"}

 result = get_weather_message("Madrid")

 assert result == "Madrid: 22°C, sunny"

// Jest stub
jest.spyOn(weatherApi, 'getCurrent').mockResolvedValue({
 temp: 22,
 condition: 'sunny',
});

test('formats weather message correctly', async () => {
 const result = await getWeatherMessage('Madrid');
 expect(result).toBe('Madrid: 22°C, sunny');
});

Spies — Verifying Interactions#

from unittest.mock import MagicMock

def test_order_sends_confirmation_email():
 email_service = MagicMock()
 order_service = OrderService(email_service=email_service)

 order_service.complete_order(order_id="ord_123")

 # Spy: verify the interaction happened correctly
 email_service.send.assert_called_once_with(
 to="customer@example.com",
 subject="Order Confirmed",
 template="order_confirmation",
 data={"order_id": "ord_123"},
 )

test('sends confirmation email on order completion', () => {
 const sendEmail = jest.fn();
 const service = new OrderService({ sendEmail });

 service.completeOrder('ord_123');

 expect(sendEmail).toHaveBeenCalledWith(
 expect.objectContaining({
 to: 'customer@example.com',
 subject: 'Order Confirmed',
 })
 );
});

Fakes — Simplified Real Implementations#

class FakeUserRepository:
 """In-memory implementation for testing."""

 def __init__(self):
 self._users = {}

 def save(self, user):
 self._users[user["id"]] = user

 def find_by_id(self, user_id):
 return self._users.get(user_id)

 def find_by_email(self, email):
 return next(
 (u for u in self._users.values() if u["email"] == email),
 None,
 )

def test_register_user_saves_and_retrieves():
 repo = FakeUserRepository()
 service = UserService(repository=repo)

 service.register(name="Alice", email="alice@test.com")

 user = repo.find_by_email("alice@test.com")
 assert user is not None
 assert user["name"] == "Alice"

When to Mock#

Good Reasons to Mock#

Reason	Example
Non-deterministic	Current time, random values, UUIDs
Slow	Network calls, database queries in unit tests
Side effects	Sending emails, charging credit cards, writing files
Unavailable	Third-party API not accessible in CI
Hard to trigger	Network timeouts, disk full, race conditions

Bad Reasons to Mock#

Reason	Better Approach
“It’s complex”	Simplify the design instead
“It’s another class I wrote”	Test them together (integration test)
“To get coverage”	Write a meaningful test instead
“Everyone else does it”	Question whether it adds value

The Over-Mocking Anti-Pattern#

Over-mocking happens when tests mock so many things that they test nothing real:

Integration Testing

Mon, 01 Jan 0001 00:00:00 +0000

Integration Testing#

Unit tests verify logic in isolation. Integration tests verify that components work together — your code with a real database, your service with a real HTTP API, your function with the real filesystem. This section covers strategies for testing these interactions reliably.

What Integration Tests Cover#

graph LR
 subgraph "Unit Test Scope"
 A[Your Code]
 end
 subgraph "Integration Test Scope"
 B[Your Code] --> C[Database]
 B --> D[External API]
 B --> E[Message Queue]
 B --> F[File System]
 end

Aspect	Unit Test	Integration Test
Dependencies	Mocked/faked	Real (or realistic containers)
Speed	Milliseconds	Seconds
What it catches	Logic errors	Wiring errors, serialization bugs, query bugs
Reliability	Deterministic	May flake if external systems are unstable
Setup complexity	Low	Medium–High

What Integration Tests Catch That Unit Tests Miss#

SQL syntax errors and wrong column names
Serialization/deserialization mismatches (JSON ↔ object)
HTTP header issues, content-type mismatches
Transaction isolation problems
Connection pool exhaustion
File permission issues
Environment variable misconfiguration

Database Testing#

Strategy 1: Testcontainers (Recommended)#

Testcontainers spins up real databases in Docker for your tests:

End-to-End Testing

Mon, 01 Jan 0001 00:00:00 +0000

End-to-End Testing#

End-to-end (E2E) tests verify complete user workflows through the full application stack — from the browser or API client, through your backend, to the database and back. They provide the highest confidence but are the slowest and most maintenance-intensive.

What E2E Tests Cover#

graph LR
 subgraph "E2E Test Scope"
 USER[User/Client] --> UI[Browser/API]
 UI --> SERVER[Backend Server]
 SERVER --> DB[(Database)]
 SERVER --> EXT[External Services]
 end

Characteristic	E2E Tests
Scope	Full system, multiple components
Speed	Seconds to minutes per test
Confidence	Highest — tests real user experience
Maintenance	High — brittle to UI/flow changes
Debugging	Hard — failures could be anywhere in the stack
Count	Few — cover critical paths only

What to E2E Test#

Critical user journeys — signup, login, checkout, payment
Cross-system flows — data that passes through multiple services
Smoke tests — “does the app start and load?” after deployment
Regression tests — for bugs that slipped through other test layers

What NOT to E2E Test#

Edge cases (use unit tests)
Every possible form validation (use unit/integration tests)
Internal API responses (use API-level integration tests)
Visual pixel-perfection (use visual regression tests separately)

Browser Testing#

Playwright (Recommended)#

// tests/e2e/checkout.spec.js
import { test, expect } from '@playwright/test';

test('user can complete checkout flow', async ({ page }) => {
 // Navigate and add item to cart
 await page.goto('/products');
 await page.click('[data-testid="product-widget"]');
 await page.click('button:text("Add to Cart")');

 // Go to cart and proceed to checkout
 await page.click('[data-testid="cart-icon"]');
 await expect(page.locator('.cart-item')).toHaveCount(1);
 await page.click('button:text("Checkout")');

 // Fill shipping information
 await page.fill('[name="address"]', '123 Test Street');
 await page.fill('[name="city"]', 'Barcelona');
 await page.fill('[name="zip"]', '08001');

 // Submit order
 await page.click('button:text("Place Order")');

 // Verify confirmation
 await expect(page.locator('.order-confirmation')).toBeVisible();
 await expect(page.locator('.order-id')).toContainText(/ORD-/);
});

Cypress#

// cypress/e2e/login.cy.js
describe('Login Flow', () => {
 beforeEach(() => {
 cy.visit('/login');
 });

 it('logs in with valid credentials', () => {
 cy.get('[data-testid="email-input"]').type('alice@example.com');
 cy.get('[data-testid="password-input"]').type('secure123');
 cy.get('[data-testid="login-button"]').click();

 cy.url().should('include', '/dashboard');
 cy.get('[data-testid="welcome-message"]')
 .should('contain', 'Welcome, Alice');
 });

 it('shows error for invalid credentials', () => {
 cy.get('[data-testid="email-input"]').type('alice@example.com');
 cy.get('[data-testid="password-input"]').type('wrong');
 cy.get('[data-testid="login-button"]').click();

 cy.get('[data-testid="error-message"]')
 .should('be.visible')
 .and('contain', 'Invalid credentials');
 cy.url().should('include', '/login');
 });
});

Playwright vs Cypress#

Feature	Playwright	Cypress
Languages	JS, Python, Java, .NET	JavaScript only
Browsers	Chromium, Firefox, WebKit	Chromium, Firefox, WebKit
Parallelism	Built-in	Requires paid Cloud
Multi-tab/window	Supported	Not supported
Network interception	Full control	Good (cy.intercept)
Auto-waiting	Built-in	Built-in
iframes	Full support	Limited
Best for	Cross-browser, multi-page apps	Single-page apps, rapid prototyping

API End-to-End Testing#

Test complete API workflows without a browser:

TDD & BDD

Mon, 01 Jan 0001 00:00:00 +0000

TDD & BDD#

Test-Driven Development (TDD) and Behaviour-Driven Development (BDD) are development workflows — not testing techniques. They change when and how you write tests, fundamentally altering your approach to design and implementation.

Test-Driven Development (TDD)#

The Red-Green-Refactor Cycle#

graph LR
 RED["🔴 RED<br/>Write a failing test"] --> GREEN["🟢 GREEN<br/>Write minimal code to pass"]
 GREEN --> REFACTOR["🔵 REFACTOR<br/>Improve design, keep green"]
 REFACTOR --> RED

Phase	What You Do	Rules
Red	Write a test that describes desired behaviour	Test must fail. If it passes, you haven’t written the right test.
Green	Write the simplest code that makes the test pass	No more code than necessary. “Fake it ’til you make it.”
Refactor	Improve code structure without changing behaviour	All tests stay green. Remove duplication.

TDD Example: Building a Password Validator#

Step 1 — Red: Write the first test

Property Testing & Fuzzing

Mon, 01 Jan 0001 00:00:00 +0000

Property Testing & Fuzzing#

Traditional unit tests verify specific examples. Property-based testing verifies that invariants hold across all possible inputs, automatically generating hundreds or thousands of test cases. Fuzzing takes this further by feeding random or mutated data to find crashes and security vulnerabilities.

Property-Based Testing#

The Core Idea#

Instead of writing:

def test_sort_specific():
 assert sort([3, 1, 2]) == [1, 2, 3]

You write:

def test_sort_property(random_list):
 result = sort(random_list)
 assert len(result) == len(random_list) # preserves length
 assert all(result[i] <= result[i+1] for i in range(len(result)-1)) # ordered
 assert set(result) == set(random_list) # same elements

The framework generates many random lists and verifies the properties hold for all of them.

Performance Testing

Mon, 01 Jan 0001 00:00:00 +0000

Performance Testing#

Performance testing validates that a system meets its speed, scalability, and stability requirements under expected and extreme conditions. It identifies bottlenecks before they reach production and provides data to support capacity planning and SLO validation.

Types of Performance Tests#

Type	Purpose	Duration	Load Pattern
Load test	Validate behavior under expected load	5–30 min	Ramp to target, hold steady
Stress test	Find breaking point	15–60 min	Ramp beyond capacity
Soak test	Detect memory leaks, resource exhaustion	2–24 hours	Constant moderate load
Spike test	Validate auto-scaling and recovery	5–15 min	Sudden burst, then drop
Breakpoint test	Find maximum capacity	Variable	Incremental ramp until failure
Benchmark	Establish baseline for comparison	1–5 min	Fixed load, repeatable

Load Testing Tools Comparison#

Feature	k6	Locust	JMeter	Gatling
Language	JavaScript	Python	XML/GUI	Scala/Java
Protocol	HTTP, gRPC, WebSocket	HTTP, custom	HTTP, JDBC, JMS, FTP	HTTP, WebSocket
Scripting	Code-first	Code-first	GUI + code	Code-first (DSL)
Resource usage	Low (Go runtime)	Medium (Python)	High (Java)	Medium (JVM)
Distributed	Built-in (k6 Cloud)	Built-in (master/worker)	JMeter Remote	Distributed by design
Reporting	CLI + JSON + Grafana	Web UI	HTML/XML reports	HTML reports
Learning curve	Low	Low	Medium	Medium
Best for	CI/CD integration, developers	Python teams, custom protocols	Enterprise, complex scenarios	High-throughput HTTP

k6 — Developer-Friendly Load Testing#

Basic Load Test#

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
 stages: [
 { duration: '1m', target: 50 }, // Ramp up to 50 users
 { duration: '3m', target: 50 }, // Hold at 50 users
 { duration: '1m', target: 100 }, // Ramp to 100 users
 { duration: '3m', target: 100 }, // Hold at 100 users
 { duration: '1m', target: 0 }, // Ramp down
 ],
 thresholds: {
 http_req_duration: ['p(95)<300', 'p(99)<500'], // SLO validation
 http_req_failed: ['rate<0.01'], // <1% error rate
 },
};

export default function () {
 const res = http.get('https://api.example.com/users');

 check(res, {
 'status is 200': (r) => r.status === 200,
 'response time < 300ms': (r) => r.timings.duration < 300,
 'body has users': (r) => JSON.parse(r.body).length > 0,
 });

 sleep(1); // Think time between requests
}

Running k6#

# Local run
k6 run load-test.js

# With custom output
k6 run --out json=results.json load-test.js

# With environment variables
k6 run -e API_URL=https://staging.example.com load-test.js

Locust — Python-Based Load Testing#

from locust import HttpUser, task, between

class WebsiteUser(HttpUser):
 wait_time = between(1, 3) # Think time: 1-3 seconds

 def on_start(self):
 """Login on start."""
 self.client.post("/login", json={
 "username": "testuser",
 "password": "testpass"
 })

 @task(3) # Weight: 3x more likely than other tasks
 def view_items(self):
 self.client.get("/api/items")

 @task(1)
 def create_item(self):
 self.client.post("/api/items", json={
 "name": "Test Item",
 "price": 29.99
 })

 @task(2)
 def view_item_detail(self):
 item_id = 42 # In practice, pick from a pool
 self.client.get(f"/api/items/{item_id}")

Running Locust#

# Start with web UI
locust -f locustfile.py --host=https://api.example.com

# Headless mode (for CI)
locust -f locustfile.py --headless -u 100 -r 10 --run-time 5m \
 --host=https://api.example.com

Stress Testing#

Push beyond expected capacity to find the breaking point and observe degradation patterns.

Contract Testing

Mon, 01 Jan 0001 00:00:00 +0000

Contract Testing#

In a microservice architecture, services communicate through APIs. Contract testing verifies that these APIs remain compatible as services evolve independently — without requiring all services to be running simultaneously.

The Problem#

Integration tests between microservices are:

Slow — requires running multiple services, databases, message brokers
Flaky — network issues, environment differences, timing
Expensive — full environment per test run
Late — failures discovered at deploy time, not development time

Contract testing catches incompatibilities at build time, in isolation.