Code Coverage & Testing Vocabulary: 25 Terms for QA and Developers
Code coverage metrics, test types, mocking, TDD, BDD, and quality assurance vocabulary for developers and QA engineers.
Testing is the language that separates professional developers from hobbyists. Whether you are a QA engineer reviewing a pull request or a backend developer defending your coverage metrics in a stand-up, knowing the right vocabulary makes the difference between being understood and being dismissed. This post covers 25 essential terms used daily in QA and engineering teams — with real conversation examples so you can start using them straight away.
Core Terms: Coverage Metrics
Code coverage — a measurement that tells you what percentage of your source code is executed when your test suite runs. It is usually broken into four subtypes:
- Line coverage — the percentage of individual lines executed during tests.
- Branch coverage — checks whether every possible branch (e.g. both sides of an
ifstatement) has been tested. - Path coverage — the most thorough metric; ensures every possible route through a function has been exercised.
- Function coverage — confirms that every function or method in the codebase has been called at least once.
“We merged it, but CI is blocking the PR — branch coverage dropped from 84% to 71% after your refactor.”
“Line coverage looks fine at 90%, but our branch coverage is terrible. We’re not testing the error paths at all.”
Test suite — the complete collection of tests for a project or component, often organised into folders by type or feature.
“The whole test suite takes 12 minutes to run locally. That’s why we only run the unit tests on pre-commit.”
“Let’s add these new edge cases to the suite before we ship the feature.”
CI gate — a mandatory check in a Continuous Integration pipeline that blocks a merge if tests fail or coverage drops below a defined threshold. Also called a required status check.
“Your PR can’t be merged — the CI gate is failing on three unit tests.”
“We added a CI gate last sprint so nobody can accidentally ship with less than 80% coverage.”
Test Types Every Developer Should Know
Unit test — a test that verifies a single function, method, or class in complete isolation from the rest of the system. Fast, focused, and the foundation of the test pyramid.
“Write a unit test for that validation function first — it has four branches and no tests at all.”
Integration test — a test that checks how two or more components work together. Slower than unit tests but catches interface mismatches that unit tests miss.
“The unit tests all pass, but the integration test for the payment service is failing. The request body format changed.”
End-to-end test (E2E) — a test that simulates a real user journey through the entire application, from the UI down to the database. The most expensive test type to write and maintain.
“The E2E suite is flaky again — Cypress times out on the checkout page whenever the staging environment is slow.”
Smoke test — a shallow, fast test run that checks whether the application starts and core functionality is working. Used to decide whether deeper testing is worth proceeding with.
“Run the smoke tests first. If the login flow is broken there is no point running the full regression suite.”
Regression test — a test that verifies that a previously working behaviour still works after a code change. Regression suites grow over time and protect against reintroducing old bugs.
“We need a regression test for that bug before we close the ticket, otherwise it will come back in three months.”
Mutation testing — an advanced technique where a tool automatically introduces small bugs (mutations) into your code to check whether your tests catch them. If a mutation survives, your tests are not strong enough.
“Our coverage is 90% but mutation testing revealed that half the tests don’t actually assert anything meaningful.”
Property-based testing — instead of writing specific example inputs, you define properties that should always hold, and the framework generates hundreds of random inputs to try to break them. Popular tools include Hypothesis (Python) and fast-check (JavaScript).
“I switched to property-based testing for the serialiser — it found an edge case with Unicode characters that I never would have thought to test manually.”
Test Doubles: Stubs, Mocks, Spies, Fakes, and Dummies
The term test double is the umbrella name for any object that replaces a real dependency in a test. There are five subtypes, and mixing them up is a common source of confusion in code reviews.
- Stub — returns hard-coded responses to calls. Used when you need a dependency to return a specific value so you can test behaviour that depends on it.
- Mock — a stub that also verifies that it was called in the expected way. If the mock was not called, or was called with the wrong arguments, the test fails.
- Spy — wraps a real object and records calls to it, allowing you to assert on how it was used without fully replacing it.
- Fake — a working but simplified implementation (e.g. an in-memory database instead of a real one).
- Dummy — an object passed to satisfy a parameter signature but never actually used in the test.
“You used a stub here, but you actually need a mock — you want to verify that the email service was called exactly once.”
“Replace the real database with a fake for these integration tests so we don’t need a live connection in CI.”
“That UserRepository in the constructor is just a dummy — the function under test never touches it.”
Test Design and Quality Concepts
Arrange-Act-Assert (AAA) — a widely adopted pattern for structuring individual tests. Arrange: set up the data and dependencies. Act: call the code under test. Assert: check the result. Keeping these three phases explicit makes tests easier to read and debug.
“Your test is hard to follow because the arrange and assert phases are mixed together. Split it into AAA.”
Test pyramid — a model that recommends having many unit tests at the base, fewer integration tests in the middle, and a small number of E2E tests at the top. Inverting the pyramid (lots of E2E, few unit tests) leads to slow, brittle test suites.
“We have barely any unit tests but hundreds of E2E tests. The pyramid is completely inverted — that’s why the suite takes 40 minutes.”
Test isolation — the principle that each test should be independent. A test must not rely on state left by a previous test, and must clean up after itself. Lack of isolation is the main cause of order-dependent failures.
“These tests only fail when run in alphabetical order — classic isolation problem. Each test needs to reset the database.”
Flaky test — a test that produces inconsistent results (passing sometimes, failing sometimes) without any change to the code. Flaky tests erode trust in the test suite and are expensive to investigate.
“That test has been flaky for two weeks. Let’s quarantine it and raise a separate ticket to fix it properly.”
TDD (Test-Driven Development) — a development workflow where you write a failing test before writing the implementation, then write the minimum code to make it pass, then refactor. Often summarised as red-green-refactor.
“If we had done TDD here we would have caught this requirement gap before writing a single line of implementation.”
BDD (Behaviour-Driven Development) — an extension of TDD that uses business-readable language (often Given / When / Then syntax) to describe the expected behaviour of a system. Encourages collaboration between developers, QA, and product managers.
“The product team can actually read the BDD specs and tell us whether the scenarios match the acceptance criteria.”
How to Use These in Conversation
In daily stand-ups and code reviews, precise vocabulary signals experience. Here are some natural patterns:
Discussing coverage: “Our line coverage looks healthy, but I want us to get branch coverage up before the next release — there are several error paths that are completely untested.”
Reviewing a pull request: “Can you add a regression test for the fix? Also, this looks like it should be a mock, not a stub — we need to assert that the notification service is actually called.”
Raising quality concerns: “The test pyramid is inverted in this service. We have 200 E2E tests and 15 unit tests. Every build takes 25 minutes and the flaky test rate is around 20%. I would recommend a refactor sprint focused on unit coverage.”
Explaining a CI failure: “The CI gate is blocking your merge because mutation testing found that three of your assertions are never actually reached. The tests pass, but they would also pass if the function returned the wrong value.”
Quick Reference Table
| Term | One-Line Definition |
|---|---|
| Code coverage | Percentage of code executed by your test suite |
| Branch coverage | Whether every if/else branch has been tested |
| Unit test | Tests a single function or class in isolation |
| Integration test | Tests how two or more components work together |
| E2E test | Simulates a full user journey through the app |
| Flaky test | A test that passes and fails inconsistently |
| Test double | Any object substituting a real dependency in a test |
| Mock | A test double that also verifies how it was called |
| Arrange-Act-Assert | Standard three-phase structure for writing tests |
| CI gate | Pipeline check that blocks merges on test failure |
Mastering this vocabulary will help you contribute more confidently in code reviews, estimation sessions, and technical interviews. Pick three terms you have never used aloud before, and look for the next opportunity to use them naturally in a stand-up or pull request comment.