Testing

1The test pyramid

A simple shape that encodes a deep truth about where to invest testing effort.

The pyramid says: have many unit tests (fast, cheap, isolated), fewer integration tests, and few end-to-end tests (slow, brittle, expensive). The reasoning is economic — unit tests give you the most confidence per second of runtime, so they should dominate, while e2e tests are precious but costly and flaky, so you use them sparingly for critical paths.

2Unit vs integration vs e2e

The levels differ in how much they exercise at once:

• Unit — one piece (a function/class) in isolation, dependencies faked. Pinpoints exactly what broke; milliseconds to run.
• Integration — several components together (e.g. service + real database), verifying they collaborate correctly. Catches the wiring bugs unit tests can't.
• End-to-end — the whole system through the user's eyes (UI → API → DB). Highest confidence that a real journey works, but slowest and most fragile.

The senior insight is the tradeoff: as you climb, confidence rises but speed, isolation, and stability fall. Each level catches bugs the others miss, so you want a deliberate mix — not all of one kind.

3TDD & BDD

Test-Driven Development inverts the usual order: write a failing test first, write the minimum code to pass it, then refactor — the red-green-refactor loop. The benefits aren't just coverage: writing the test first forces you to design the interface from the caller's perspective and guarantees the code is testable. The discipline produces a comprehensive safety net as a byproduct.

Behavior-Driven Development raises TDD to the language of behaviour, using Given-When-Then scenarios that non-engineers can read (tools like Cucumber). The point is shared understanding — the test doubles as a specification the whole team, including product, agrees on. TDD is about how you build; BDD is about aligning on what to build.

4Test doubles — mocking, stubbing, faking

To test a unit in isolation, you replace its real dependencies with test doubles. The distinctions are a favourite precision check:

• Stub — returns canned answers to calls (e.g. "this method always returns user 42"). Used to control state.
• Mock — a stub that also verifies interactions ("was save() called exactly once?"). Used to assert behaviour.
• Fake — a lightweight working implementation (e.g. an in-memory database) — real logic, just not production-grade.

5UI automation — Selenium vs Playwright vs Cypress

These automate a real browser to test the UI end-to-end. Know them at a glance: Selenium is the veteran — broad language and browser support, but older and more flake-prone. Cypress runs inside the browser with a great developer experience and time-travel debugging, but is more frontend-focused. Playwright (Microsoft) is the modern favourite — fast, cross-browser, with auto-waiting that kills much of the flakiness.

The deeper point transcends the tool: UI tests are inherently the most brittle, so you keep them few (the pyramid), target stable selectors (data-testid, not CSS classes), and lean on auto-waiting over hard-coded sleeps. Showing you know why UI tests flake — and how to reduce it — matters more than naming a favourite.

6API testing

API tests sit in the sweet spot: more realistic than unit tests, far more stable and fast than UI tests, because they skip the brittle browser layer and hit the contract directly. You verify status codes, response shape, error handling, auth, and edge cases at the HTTP boundary — tools like Postman for exploration, and code (REST-assured, supertest, requests) in CI.

Because they exercise real integration without UI fragility, API/service tests are where a lot of teams concentrate their integration coverage — a pragmatic refinement of the pyramid. Mentioning contract testing (Pact) — verifying that a producer and consumer agree on the API shape — is a sharp, senior addition for microservice contexts.

7Performance testing

Performance testing measures behaviour under load, and the vocabulary distinctions are the interview substance:

• Load testing — expected traffic; does it meet latency/throughput targets?
• Stress testing — push past limits to find the breaking point and see how it fails.
• Soak testing — sustained load over hours to expose leaks and slow degradation.
• Spike testing — sudden surges, e.g. a flash sale.

Report results in percentiles, not averages — p95/p99 latency reveals the tail of slow requests that an average hides. "Average response time looks fine but p99 is 4 seconds" is exactly the kind of insight that signals you understand real user experience.

8Security testing — SAST & DAST

Two complementary approaches, tied back to Module 05. SAST (Static Application Security Testing) analyses source code without running it — catching issues like injection patterns or hardcoded secrets early, right in the pipeline ("shift left"). DAST (Dynamic) tests the running application from the outside, like an attacker, probing for exploitable vulnerabilities the code alone won't reveal.

The clean framing: SAST reads the code; DAST attacks the app — you want both, at different pipeline stages. Add SCA (Software Composition Analysis — scanning dependencies for known CVEs) and you've covered the three automated security checks every mature pipeline runs.

9Bug lifecycle, severity vs priority

A bug flows through a lifecycle: New → Assigned → In Progress → Fixed → In Test → Verified → Closed (or Reopened). Knowing it shows you've worked a real tracker (Module 02). The distinction that trips people up is the important one:

• Severity — technical impact of the bug (crash vs cosmetic). Set by engineering/QA.
• Priority — business urgency to fix. Set by product.

They're independent: a typo in the company name on the homepage is low severity but high priority; an obscure crash in a feature nobody uses is high severity, low priority. Being able to give that cross-example is the senior tell.

10What "good test coverage" means

Code coverage measures the percentage of code executed by tests — useful as a signal, dangerous as a target. The trap: 100% coverage proves every line ran, not that anything was asserted correctly. You can have 100% coverage with tests that check nothing.

Good coverage is about testing the right things: critical business logic, edge cases, error paths, and boundaries — not trivial getters chased for a number. The mature stance: coverage is a conversation-starter ("this critical module has 20% — why?"), and you'd rather have 70% coverage of meaningful behaviour than 95% of trivia. The real goal is confidence to change code safely, which is what testing actually buys you.