5 exercises — core testing terms: unit vs integration tests, E2E tests, mocks vs stubs, test coverage, and flaky tests. Essential for QA engineers and developers who write tests.
Key testing vocabulary clusters
Test types: unit · integration · E2E · smoke · regression · acceptance · performance · load · mutation
Test doubles: mock (records calls) · stub (returns preset values) · fake (working lightweight impl) · spy (wraps real impl)
Metrics: test coverage · line coverage · branch coverage · flakiness · pass rate · build time
What is the difference between a unit test and an integration test?
Unit tests test the smallest pieces of logic (a function, a method, a class) in isolation — all dependencies are replaced with mocks/stubs. They run fast (milliseconds) and are the base of the testing pyramid. Integration tests verify that multiple components interact correctly — e.g. a service + database, or two microservices communicating. They are slower and require more infrastructure. The testing pyramid: many unit tests (base) → fewer integration tests → even fewer end-to-end (E2E) tests (top). Related: system tests (full system), acceptance tests (meets business requirements), regression tests (existing behaviour hasn't broken).
2 / 5
Complete with the correct QA term: "The new feature is failing in production but all our tests pass — we need to add a _____ test that exercises the full user flow from login to checkout to catch this kind of issue."
An end-to-end (E2E) test simulates a real user flow through the entire application — browser, frontend, API, database, and any external services. Tools: Playwright, Cypress, Selenium. E2E tests catch integration bugs that unit and integration tests miss because they test the real system, not isolated parts. Trade-offs: slow (seconds to minutes per test), flaky (dependent on timing, network, external services), expensive to maintain. That's why there are fewer of them in the testing pyramid. Smoke tests are a subset of E2E tests — a small set of critical tests run after every deployment to confirm the system is basically working ("is the smoke alarm going off?").
3 / 5
In testing, what is a mock?
A mock is a fake implementation of a dependency (a service, database, or API) that records which methods were called, with which arguments, and how many times — allowing you to assert on interactions. Compare: stub (a simple fake that just returns preset values, no interaction tracking), fake (a lightweight working implementation — e.g. an in-memory database), spy (wraps the real implementation and records calls). The rule of thumb: use stubs when you only care about the return value; use mocks when you want to verify that a specific call happened. Over-mocking leads to brittle tests that pass even when the real integration is broken.
4 / 5
What is test coverage and why is 100% coverage not always a meaningful goal?
Test coverage (usually line or branch coverage) measures what percentage of code is executed when the test suite runs. Types: line coverage (which lines were hit), branch coverage (which if/else branches), path coverage (all execution paths). Why 100% isn't always meaningful: a line can be executed but not tested for the correct behaviour — you can have 100% line coverage with zero assertions. What matters is what you test, not just that you touched every line. High-coverage, low-quality tests give false confidence. Better signals: mutation testing (does changing the code break a test?), meaningful assertions, testing edge cases.
5 / 5
What are flaky tests and why are they a problem?
Flaky tests are non-deterministic — they sometimes pass and sometimes fail for the same codebase, with no code change. Root causes: timing issues (setTimeout, async races), test order dependencies (test A leaves state that breaks test B), external services (real network calls in tests), random data generation, shared mutable state. Why they're a serious problem: they erode trust in the test suite — developers start ignoring red CI builds ("it's probably flaky"). Fix strategies: add proper waits/assertions instead of fixed delays, isolate tests, mock external dependencies, run flaky tests in quarantine. Teams often track a "flakiness score" as an engineering metric.