Software Testing — ทดสอบยังไงให้มั่นใจก่อน Deploy 🧪Software Testing — How to Be Sure Before You Deploy 🧪

// math.js
function add(a, b) {
  return a + b;
}

function divide(a, b) {
  if (b === 0) throw new Error('Cannot divide by zero');
  return a / b;
}

module.exports = { add, divide };

// math.test.js
const { add, divide } = require('./math');

describe('add', () => {
  test('adds two positive numbers', () => {
    expect(add(2, 3)).toBe(5);
  });

  test('adds negative numbers', () => {
    expect(add(-1, -2)).toBe(-3);
  });

  test('adds zero', () => {
    expect(add(5, 0)).toBe(5);
  });
});

describe('divide', () => {
  test('divides two numbers', () => {
    expect(divide(10, 2)).toBe(5);
  });

  test('throws on divide by zero', () => {
    expect(() => divide(10, 0)).toThrow('Cannot divide by zero');
  });

  test('returns float result', () => {
    expect(divide(7, 2)).toBeCloseTo(3.5);
  });
});

# รัน tests
npx jest
# PASS  ./math.test.js
#   add
#     ✓ adds two positive numbers (2ms)
#     ✓ adds negative numbers (1ms)
#     ✓ adds zero (1ms)
#   divide
#     ✓ divides two numbers (1ms)
#     ✓ throws on divide by zero (1ms)
#     ✓ returns float result (1ms)
#
# Tests: 6 passed, 6 total

# calculator.py
class Calculator:
    def add(self, a, b):
        return a + b

    def divide(self, a, b):
        if b == 0:
            raise ValueError("Cannot divide by zero")
        return a / b

# test_calculator.py
import pytest
from calculator import Calculator

@pytest.fixture
def calc():
    return Calculator()

def test_add(calc):
    assert calc.add(2, 3) == 5

def test_add_negative(calc):
    assert calc.add(-1, -2) == -3

def test_divide(calc):
    assert calc.divide(10, 2) == 5.0

def test_divide_by_zero(calc):
    with pytest.raises(ValueError, match="Cannot divide by zero"):
        calc.divide(10, 0)

# รัน tests
pytest -v
# test_calculator.py::test_add PASSED
# test_calculator.py::test_add_negative PASSED
# test_calculator.py::test_divide PASSED
# test_calculator.py::test_divide_by_zero PASSED
#
# 4 passed in 0.02s

// userService.test.js
const { getUserName } = require('./userService');
const db = require('./database');

// Mock database module
jest.mock('./database');

test('returns user name from database', async () => {
  // จำลองว่า DB return ข้อมูลนี้
  db.findUser.mockResolvedValue({ id: 1, name: 'สมชาย' });

  const name = await getUserName(1);
  expect(name).toBe('สมชาย');
  expect(db.findUser).toHaveBeenCalledWith(1);
});

test('returns "Unknown" when user not found', async () => {
  db.findUser.mockResolvedValue(null);

  const name = await getUserName(999);
  expect(name).toBe('Unknown');
});

// api.integration.test.js
const request = require('supertest');
const app = require('./app');
const db = require('./database');

beforeAll(async () => {
  await db.connect();        // ใช้ test database จริง
  await db.seed();            // ใส่ข้อมูลทดสอบ
});

afterAll(async () => {
  await db.cleanup();
  await db.disconnect();
});

describe('GET /api/users', () => {
  test('returns list of users', async () => {
    const res = await request(app)
      .get('/api/users')
      .expect(200);

    expect(res.body).toHaveLength(3);
    expect(res.body[0]).toHaveProperty('name');
    expect(res.body[0]).toHaveProperty('email');
  });
});

describe('POST /api/users', () => {
  test('creates a new user', async () => {
    const res = await request(app)
      .post('/api/users')
      .send({ name: 'สมหญิง', email: '[email protected]' })
      .expect(201);

    expect(res.body.name).toBe('สมหญิง');
    expect(res.body.id).toBeDefined();
  });

  test('returns 400 for invalid email', async () => {
    const res = await request(app)
      .post('/api/users')
      .send({ name: 'Test', email: 'invalid' })
      .expect(400);

    expect(res.body.error).toContain('email');
  });
});

# docker-compose.test.yml
version: '3.8'
services:
  app:
    build: .
    environment:
      - DATABASE_URL=postgres://test:test@db:5432/testdb
      - NODE_ENV=test
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres:16-alpine
    environment:
      - POSTGRES_USER=test
      - POSTGRES_PASSWORD=test
      - POSTGRES_DB=testdb
    healthcheck:
      test: pg_isready -U test
      interval: 5s
      retries: 5

# รัน integration tests ใน Docker
docker compose -f docker-compose.test.yml run --rm app npm test

// tests/login.spec.js
const { test, expect } = require('@playwright/test');

test.describe('Login Flow', () => {
  test('successful login', async ({ page }) => {
    await page.goto('http://localhost:3000/login');

    // กรอก form
    await page.fill('[data-testid="email"]', '[email protected]');
    await page.fill('[data-testid="password"]', 'P@ssw0rd');
    await page.click('[data-testid="login-btn"]');

    // ตรวจว่า redirect ไป dashboard
    await expect(page).toHaveURL('/dashboard');
    await expect(page.locator('h1')).toContainText('Welcome');
  });

  test('shows error on wrong password', async ({ page }) => {
    await page.goto('http://localhost:3000/login');

    await page.fill('[data-testid="email"]', '[email protected]');
    await page.fill('[data-testid="password"]', 'wrongpassword');
    await page.click('[data-testid="login-btn"]');

    // ต้องแสดง error message
    await expect(page.locator('.error-message')).toBeVisible();
    await expect(page.locator('.error-message')).toContainText('Invalid');
  });

  test('checkout flow', async ({ page }) => {
    await page.goto('http://localhost:3000');

    // เลือกสินค้า
    await page.click('[data-testid="product-1"]');
    await page.click('[data-testid="add-to-cart"]');

    // ไป checkout
    await page.click('[data-testid="cart-icon"]');
    await page.click('[data-testid="checkout-btn"]');

    // กรอกข้อมูล
    await page.fill('#address', '123 Bangkok');
    await page.click('[data-testid="confirm-order"]');

    // ตรวจว่าสำเร็จ
    await expect(page.locator('.order-success')).toBeVisible();
  });
});

# ติดตั้ง Playwright
npm init playwright@latest

# รัน tests
npx playwright test

# รัน + เปิด browser ให้ดู
npx playwright test --headed

# ดู HTML report
npx playwright show-report

// cypress/e2e/login.cy.js
describe('Login', () => {
  it('logs in successfully', () => {
    cy.visit('/login');
    cy.get('[data-testid="email"]').type('[email protected]');
    cy.get('[data-testid="password"]').type('P@ssw0rd');
    cy.get('[data-testid="login-btn"]').click();
    cy.url().should('include', '/dashboard');
    cy.contains('h1', 'Welcome');
  });
});

# Jest + Coverage
npx jest --coverage

# Output:
# ----------|---------|----------|---------|---------|
# File      | % Stmts | % Branch | % Funcs | % Lines |
# ----------|---------|----------|---------|---------|
# All files |   92.5  |   85.0   |   100   |   92.5  |
#  math.js  |   100   |   100    |   100   |   100   |
#  user.js  |   85.0  |   70.0   |   100   |   85.0  |
# ----------|---------|----------|---------|---------|

# pytest + Coverage
pytest --cov=src --cov-report=html
# → เปิด htmlcov/index.html ดู visual report

// Step 1: 🔴 Red — เขียน test ก่อน (จะ fail)
test('validates email format', () => {
  expect(isValidEmail('[email protected]')).toBe(true);
  expect(isValidEmail('invalid')).toBe(false);
  expect(isValidEmail('')).toBe(false);
  expect(isValidEmail('[email protected]')).toBe(true);
});
// ❌ ReferenceError: isValidEmail is not defined

// Step 2: 🟢 Green — เขียน code ง่ายๆ ให้ pass
function isValidEmail(email) {
  return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email);
}
// ✅ All tests pass!

// Step 3: 🔵 Refactor — ปรับปรุง (ถ้าจำเป็น)
// → code ดีอยู่แล้ว ไป feature ถัดไป!

# .github/workflows/test.yml
name: Test
on: [push, pull_request]

jobs:
  unit-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'
      - run: npm ci
      - run: npm test -- --coverage
      - name: Upload coverage
        uses: codecov/codecov-action@v4

  integration-test:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_PASSWORD: test
        ports: ['5432:5432']
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-retries 5
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run test:integration
        env:
          DATABASE_URL: postgres://postgres:test@localhost:5432/postgres

  e2e-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npm run build
      - run: npx playwright test
      - uses: actions/upload-artifact@v4
        if: failure()
        with:
          name: playwright-report
          path: playwright-report/

In the previous post we learned about DevSecOps — security embedded in every step.

But before anything can go to production... how do we know the code is actually correct? You fix a bug here — does something break over there? 🤔

The answer is Software Testing — writing code that tests your code, the way a scientist repeats an experiment before drawing any conclusion 🧪🐕

---

Testing Pyramid — How Many Levels of Testing?

The Testing Pyramid is the idea that tells you which kinds of test to write and in what proportion. The bottom layer (Unit Tests) should be the largest, because those tests are fast and easy. The higher you climb (Integration → E2E), the fewer you write, because they are slow, expensive and hard to maintain. Write too many E2E tests and the pipeline crawls; write only unit tests and you never find out whether the components really work together — you have to find the balance:

Level	What it tests	Speed	How many
Unit	One function/method at a time	⚡ Very fast (ms)	The most (70-80%)
Integration	Several components together	🔄 Moderate (s)	Moderate (15-20%)
E2E	The whole system, simulating a user	🐢 Slow (min)	The fewest (5-10%)

💡 The golden rule: many unit tests (fast, cheap), few E2E tests (slow, expensive) — like a pyramid, wide at the base and narrow at the top

---

⚡ Unit Testing — One Piece at a Time

A unit test exercises one function or one class in isolation — no database, no API, no external services. The goal is to confirm that "given this input, you must get that output". When a unit test fails you know immediately which function holds the bug, with no hunting through the whole system. They are extremely fast (milliseconds), so you can run them on every save.

JavaScript (Jest)

Jest is the most popular testing framework for JavaScript/TypeScript — test runner, assertions and mocking are all built in. The example below shows what good unit tests look like, covering the happy path, the edge cases and error handling:

// math.js
function add(a, b) {
  return a + b;
}

function divide(a, b) {
  if (b === 0) throw new Error('Cannot divide by zero');
  return a / b;
}

module.exports = { add, divide };

// math.test.js
const { add, divide } = require('./math');

describe('add', () => {
  test('adds two positive numbers', () => {
    expect(add(2, 3)).toBe(5);
  });

  test('adds negative numbers', () => {
    expect(add(-1, -2)).toBe(-3);
  });

  test('adds zero', () => {
    expect(add(5, 0)).toBe(5);
  });
});

describe('divide', () => {
  test('divides two numbers', () => {
    expect(divide(10, 2)).toBe(5);
  });

  test('throws on divide by zero', () => {
    expect(() => divide(10, 0)).toThrow('Cannot divide by zero');
  });

  test('returns float result', () => {
    expect(divide(7, 2)).toBeCloseTo(3.5);
  });
});

# Run the tests
npx jest
# PASS  ./math.test.js
#   add
#     ✓ adds two positive numbers (2ms)
#     ✓ adds negative numbers (1ms)
#     ✓ adds zero (1ms)
#   divide
#     ✓ divides two numbers (1ms)
#     ✓ throws on divide by zero (1ms)
#     ✓ returns float result (1ms)
#
# Tests: 6 passed, 6 total

Python (pytest)

pytest is a powerful testing framework for Python — its standout features are fixtures (reusable setup/teardown) and parametrize (many cases from a single decorator). Tests come out far shorter than the unittest equivalent:

# calculator.py
class Calculator:
    def add(self, a, b):
        return a + b

    def divide(self, a, b):
        if b == 0:
            raise ValueError("Cannot divide by zero")
        return a / b

# test_calculator.py
import pytest
from calculator import Calculator

@pytest.fixture
def calc():
    return Calculator()

def test_add(calc):
    assert calc.add(2, 3) == 5

def test_add_negative(calc):
    assert calc.add(-1, -2) == -3

def test_divide(calc):
    assert calc.divide(10, 2) == 5.0

def test_divide_by_zero(calc):
    with pytest.raises(ValueError, match="Cannot divide by zero"):
        calc.divide(10, 0)

# Run the tests
pytest -v
# test_calculator.py::test_add PASSED
# test_calculator.py::test_add_negative PASSED
# test_calculator.py::test_divide PASSED
# test_calculator.py::test_divide_by_zero PASSED
#
# 4 passed in 0.02s

Mocking — Standing In for Dependencies

Mocking means building a stand-in for a real dependency — a database call, an HTTP request, an email service. It keeps unit tests free of external services (faster, more stable) and lets you test the error cases too (pretending the DB is down, for instance):

// userService.test.js
const { getUserName } = require('./userService');
const db = require('./database');

// Mock database module
jest.mock('./database');

test('returns user name from database', async () => {
  // pretend the DB returns this
  db.findUser.mockResolvedValue({ id: 1, name: 'Somchai' });

  const name = await getUserName(1);
  expect(name).toBe('Somchai');
  expect(db.findUser).toHaveBeenCalledWith(1);
});

test('returns "Unknown" when user not found', async () => {
  db.findUser.mockResolvedValue(null);

  const name = await getUserName(999);
  expect(name).toBe('Unknown');
});

💡 Why mock at all? A unit test has to be fast and isolated — no real DB, no real API, no real filesystem

---

🔗 Integration Testing — The Pieces Working Together

An integration test checks that several components really work together — API endpoint → business logic → database → response. Unlike a unit test it uses the real things (database, Redis, external APIs), which is how it catches the bugs unit tests cannot: a wrong SQL query, connection pooling issues, serialization problems:

// api.integration.test.js
const request = require('supertest');
const app = require('./app');
const db = require('./database');

beforeAll(async () => {
  await db.connect();        // use a real test database
  await db.seed();            // load the test data
});

afterAll(async () => {
  await db.cleanup();
  await db.disconnect();
});

describe('GET /api/users', () => {
  test('returns list of users', async () => {
    const res = await request(app)
      .get('/api/users')
      .expect(200);

    expect(res.body).toHaveLength(3);
    expect(res.body[0]).toHaveProperty('name');
    expect(res.body[0]).toHaveProperty('email');
  });
});

describe('POST /api/users', () => {
  test('creates a new user', async () => {
    const res = await request(app)
      .post('/api/users')
      .send({ name: 'Somying', email: '[email protected]' })
      .expect(201);

    expect(res.body.name).toBe('Somying');
    expect(res.body.id).toBeDefined();
  });

  test('returns 400 for invalid email', async () => {
    const res = await request(app)
      .post('/api/users')
      .send({ name: 'Test', email: 'invalid' })
      .expect(400);

    expect(res.body.error).toContain('email');
  });
});

Docker Compose for Integration Tests

The problem with integration tests is that they need a database, Redis and the rest actually running. Docker Compose solves this perfectly — every service you need comes up with a single command, it runs in CI too, and everyone gets the identical environment:

# docker-compose.test.yml
version: '3.8'
services:
  app:
    build: .
    environment:
      - DATABASE_URL=postgres://test:test@db:5432/testdb
      - NODE_ENV=test
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres:16-alpine
    environment:
      - POSTGRES_USER=test
      - POSTGRES_PASSWORD=test
      - POSTGRES_DB=testdb
    healthcheck:
      test: pg_isready -U test
      interval: 5s
      retries: 5

# Run the integration tests in Docker
docker compose -f docker-compose.test.yml run --rm app npm test

---

🖥️ E2E Testing — Testing Like a Real User

An E2E (End-to-End) test imitates a real user — it opens a browser, clicks buttons, fills forms and checks that the screen shows the right thing. It exercises everything from frontend → API → database → response, and it catches bugs that unit and integration tests miss (a button left disabled, a broken responsive layout, a JS error that only appears in a real browser).

⚠️ But E2E tests are slow (minutes, not seconds) and flaky (they depend on timing, the network, the browser version). Write them only for the critical paths — login, checkout, registration — not for every feature.

Playwright (recommended!)

Playwright is the best E2E framework available today — faster than Cypress, multi-browser (Chrome, Firefox, Safari), with genuinely smart auto-waiting, automatic screenshots and video when a test fails, and a codegen tool that records what you do in the browser and writes the test for you:

// tests/login.spec.js
const { test, expect } = require('@playwright/test');

test.describe('Login Flow', () => {
  test('successful login', async ({ page }) => {
    await page.goto('http://localhost:3000/login');

    // fill in the form
    await page.fill('[data-testid="email"]', '[email protected]');
    await page.fill('[data-testid="password"]', 'P@ssw0rd');
    await page.click('[data-testid="login-btn"]');

    // check that it redirects to the dashboard
    await expect(page).toHaveURL('/dashboard');
    await expect(page.locator('h1')).toContainText('Welcome');
  });

  test('shows error on wrong password', async ({ page }) => {
    await page.goto('http://localhost:3000/login');

    await page.fill('[data-testid="email"]', '[email protected]');
    await page.fill('[data-testid="password"]', 'wrongpassword');
    await page.click('[data-testid="login-btn"]');

    // an error message must appear
    await expect(page.locator('.error-message')).toBeVisible();
    await expect(page.locator('.error-message')).toContainText('Invalid');
  });

  test('checkout flow', async ({ page }) => {
    await page.goto('http://localhost:3000');

    // pick a product
    await page.click('[data-testid="product-1"]');
    await page.click('[data-testid="add-to-cart"]');

    // go to checkout
    await page.click('[data-testid="cart-icon"]');
    await page.click('[data-testid="checkout-btn"]');

    // fill in the details
    await page.fill('#address', '123 Bangkok');
    await page.click('[data-testid="confirm-order"]');

    // check that it succeeded
    await expect(page.locator('.order-success')).toBeVisible();
  });
});

# Install Playwright
npm init playwright@latest

# Run the tests
npx playwright test

# Run with the browser visible
npx playwright test --headed

# View the HTML report
npx playwright show-report

Cypress (the other popular choice)

Cypress used to be the most popular E2E framework of all — its strengths are time-travel debugging (a snapshot at every step) and an excellent developer experience. But it supports only Chromium-based browsers and is slower than Playwright. Playwright is overtaking it now, though Cypress remains a good option:

// cypress/e2e/login.cy.js
describe('Login', () => {
  it('logs in successfully', () => {
    cy.visit('/login');
    cy.get('[data-testid="email"]').type('[email protected]');
    cy.get('[data-testid="password"]').type('P@ssw0rd');
    cy.get('[data-testid="login-btn"]').click();
    cy.url().should('include', '/dashboard');
    cy.contains('h1', 'Welcome');
  });
});

---

📊 Code Coverage — How Much Is Actually Covered?

Code coverage measures what percentage of your code the tests actually "pass through" — there are four kinds: line coverage (how many lines were reached), branch coverage (was every if/else taken?), function coverage (was every function called?), and statement coverage. The usual recommendation is 80% or above, but 100% does not mean bug-free — coverage only tells you the code was reached, not that the test checked the output correctly:

# Jest + Coverage
npx jest --coverage

# Output:
# ----------|---------|----------|---------|---------|
# File      | % Stmts | % Branch | % Funcs | % Lines |
# ----------|---------|----------|---------|---------|
# All files |   92.5  |   85.0   |   100   |   92.5  |
#  math.js  |   100   |   100    |   100   |   100   |
#  user.js  |   85.0  |   70.0   |   100   |   85.0  |
# ----------|---------|----------|---------|---------|

# pytest + Coverage
pytest --cov=src --cov-report=html
# → open htmlcov/index.html for the visual report

Coverage %	Rating	Advice
80-100%	Excellent	A good target — you don't need 100%
60-80%	Acceptable	Room to improve — focus on the critical paths
< 60%	Low	Add tests! You are risking production bugs

🐕 Careful! 100% coverage ≠ 100% bug-free — coverage measures whether the code was "run", not whether it is "correct". You still have to write good assertions!

---

🔄 TDD — Test-Driven Development

TDD (Test-Driven Development) is writing code "upside down" — write the test first (it fails, because the code does not exist yet) → write code until the test passes → refactor until it is clean, then repeat. The cycle is called Red-Green-Refactor. The payoff is that every line has test coverage from the very beginning, and the design comes out better because you are forced to think from the caller's side (the test) first:

// Step 1: 🔴 Red — write the test first (it will fail)
test('validates email format', () => {
  expect(isValidEmail('[email protected]')).toBe(true);
  expect(isValidEmail('invalid')).toBe(false);
  expect(isValidEmail('')).toBe(false);
  expect(isValidEmail('[email protected]')).toBe(true);
});
// ❌ ReferenceError: isValidEmail is not defined

// Step 2: 🟢 Green — write the simplest code that passes
function isValidEmail(email) {
  return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email);
}
// ✅ All tests pass!

// Step 3: 🔵 Refactor — improve it (if it needs it)
// → the code is already fine, on to the next feature!

---

🚀 Testing in the CI/CD Pipeline

Once the tests are written they have to run automatically on every PR — not lean on a developer's "diligence"! GitHub Actions runs the whole suite automatically on every push and every PR. If a test fails → the PR cannot be merged, and the bug never reaches production:

GitHub Actions

Here is a pipeline that runs all three levels — unit tests first (the fastest), then integration tests (which need a PostgreSQL container), then E2E tests (which need a browser). Fastest to slowest, so that it fails fast:

# .github/workflows/test.yml
name: Test
on: [push, pull_request]

jobs:
  unit-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'
      - run: npm ci
      - run: npm test -- --coverage
      - name: Upload coverage
        uses: codecov/codecov-action@v4

  integration-test:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_PASSWORD: test
        ports: ['5432:5432']
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-retries 5
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run test:integration
        env:
          DATABASE_URL: postgres://postgres:test@localhost:5432/postgres

  e2e-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npm run build
      - run: npx playwright test
      - uses: actions/upload-artifact@v4
        if: failure()
        with:
          name: playwright-report
          path: playwright-report/

---

🛠️ Testing Tools — Which One Should You Pick?

Every language has several testing tools — the table below sums up the popular choices by test type, so you can pick quickly. Start with the main framework (Jest/pytest), then add E2E and coverage later:

Language	Unit / Integration	E2E
JavaScript	Jest, Vitest, Mocha	Playwright, Cypress
Python	pytest, unittest	Playwright, Selenium
Java	JUnit, TestNG	Selenium, Playwright
Go	testing (built-in)	Playwright
API Testing	Supertest, httpx	Postman, k6
Load Testing	—	k6, Locust, Artillery

---

📋 Testing Best Practices

Writing good tests is more than merely "having tests" — they have to be easy to read, easy to maintain, fast to run and trustworthy (not flaky). The practices worth following:

1. Test Pyramid: many Unit → some Integration → few E2E
2. AAA Pattern: Arrange (set up) → Act (do it) → Assert (check it)
3. Good test names: "returns 404 when user not found", not "test1"
4. Independent: no test depends on another — they can run in any order
5. Fast: unit tests must be quick (< 1 sec for the whole suite)
6. Mock external: never call a real API or DB from a unit test
7. CI/CD: every push must run the tests automatically
8. Coverage > 80%: but aim at the critical paths, not the number

💡 Remember: "A test that does not run in CI is not a test" — every test belongs in the pipeline!

---

Summary

Software testing is not "extra work" — it is the highest-return investment in software development. Write a test today and save yourself hours of debugging later. Teams with good tests deploy faster and with more confidence:

• Testing Pyramid = Unit (many, fast) → Integration (some) → E2E (few, slow)
• Unit Test = one function at a time, with mocks standing in for dependencies
• Integration Test = several components together (API + DB)
• E2E Test = a simulated real user (Playwright / Cypress)
• TDD = Red → Green → Refactor — the test comes before the code
• Code Coverage = aim > 80%, but for quality, not for the number
• CI/CD = every push runs the tests automatically 🧪🐕