5 exercises on naming the levels of testing — unit, integration, end-to-end, smoke and contract tests, the test pyramid, and edge vs happy path.
Key patterns
unit test → one component in isolation
integration test → components working together
end-to-end (E2E) test → the whole flow as a user
smoke test → quick "does it boot?" check
happy path vs edge case / boundary
0 / 5 completed
1 / 5
A test architect explains the strategy: "Most of our tests should be fast, isolated ___ tests at the base, with fewer integration and E2E tests on top." Which term completes this description of the standard test strategy?
Unit tests — the base of the test pyramid:
The test pyramid is the canonical model for balancing test types. The metaphor describes proportion: many cheap, fast tests at the bottom, few slow, expensive ones at the top.
Unit tests (base) — test a single function or class in isolation; fast and numerous
Integration tests (middle) — test how components work together (e.g. service + database)
End-to-end (E2E) tests (top) — drive the whole system through the UI; slow and brittle, so kept few
Key collocations:
"the base of the pyramid" / "the top of the pyramid"
"push tests down the pyramid" — prefer cheaper unit tests
"an inverted pyramid / ice-cream cone" — the anti-pattern of too many E2E tests
Why not the others? Smoke, contract and acceptance tests describe a test’s purpose, not its position at the pyramid base. The defining feature there is isolation — the signature of a unit test.
2 / 5
A QA engineer reviewing a deploy says: "Before running the full suite, let’s ___ a quick ___ test to confirm the app even boots." Which option fills both blanks naturally?
Run a smoke test — the sanity-check collocation:
A smoke test (the name comes from hardware: power it on and see if it smokes) is a minimal, broad check that the most critical paths work — "does it even start?" It is run before deeper testing to avoid wasting time on a fundamentally broken build.
"run a smoke test" / "smoke-test the build" (verb)
"the deploy passed smoke tests"
"a smoke suite" — the small set of these checks
Verb choice: tests are run (or executed), never "done" or "made". You write a test, then run it.
Contrast the distractors: a regression test guards an old feature against breaking; boundary and edge-case testing probe specific input limits — none of these is a quick "does it boot?" check.
3 / 5
A tester describes their coverage gap: "The function works for typical input, but it crashes on an empty list — we never tested that ___." Which term names an unusual-but-valid input that breaks code?
Edge case — the input at the boundary of expected behaviour:
An edge case is an unusual or extreme input that sits at the limits of what the code is designed to handle — empty lists, zero, negative numbers, maximum lengths, null values, the first/last element.
"handle an edge case" / "cover the edge cases"
"this fails on an edge case"
"a corner case" — near-synonym, often for a combination of two edge conditions at once
Contrast with the happy path: the happy path is the normal, expected flow where everything goes right and the user does exactly what you anticipate. Good tests cover both: "we test the happy path and the edge cases."
Related:boundary testing deliberately probes the values right at an edge — e.g. for a 1–100 range, test 0, 1, 100 and 101.
4 / 5
Two microservice teams agree on an API format and add a test that fails if either side changes the shape unexpectedly. A developer says: "That’s our ___ test — it verifies both services still honour the agreed interface."
Contract test — verifying the agreement between services:
A contract test checks that the interface ("contract") between a consumer and a provider is honoured — the request/response shape, fields and types both sides rely on. It catches breaking API changes without spinning up the whole system.
"consumer-driven contract testing" — the consumer defines its expectations
"the contract between services"
"this change breaks the contract"
tools: Pact, Spring Cloud Contract
Why not the others? A unit test checks one component in isolation, not an inter-service agreement; a smoke test is a broad boot check; a load test measures performance under volume. The defining idea here is two parties honouring a shared contract.
5 / 5
A QA lead describes their full-stack verification: "We need an ___ test that drives the real browser, logs in, adds an item to the basket, and checks out — exactly like a user would."
End-to-end (E2E) test — the whole journey, as a real user:
An end-to-end test exercises a complete user flow through the real, running system — UI, services, database — verifying everything works together from start to finish.
"end-to-end test" (often abbreviated E2E)
"drive the browser" / "walk through the full flow"
"simulate a real user"
tools: Cypress, Playwright, Selenium
How it differs from its neighbours:
Unit — one function, fully isolated, mocked dependencies
Integration — a few components together (e.g. service + DB), but not the whole UI flow
E2E — the entire stack, through the real interface, end to end
E2E tests give the most confidence but are the slowest and most brittle, which is why they sit at the top of the test pyramid and are kept few.