Testing Vocabulary: Unit Tests, Mocks, Stubs, and More
Essential software testing vocabulary explained: unit tests, integration tests, mocks, stubs, fakes, test coverage, TDD, BDD, regression testing, and 20 more terms.
Testing has its own vocabulary — and parts of it are genuinely confusing even to experienced developers. What is the difference between a mock and a stub? When is it an integration test vs. an end-to-end test? This guide clarifies the most important testing terms so you can discuss testing strategy clearly with your team.
Types of Tests
Unit Test
A unit test tests a single, isolated piece of functionality — typically one function or one class method — in isolation from its dependencies.
“I wrote unit tests for the discount calculation logic.”
Key characteristic: fast, isolated, no external dependencies (database, file system, network).
Integration Test
An integration test tests how multiple components interact with each other. It may involve a real database, a real API call, or multiple modules working together.
“The integration tests check that the payment service correctly calls the billing API.”
Slower than unit tests, but catches issues that unit tests miss (mismatched interfaces, configuration errors, etc.).
End-to-End Test (E2E)
An end-to-end test tests the entire application flow from a user’s perspective — from the UI through the backend to the database and back. Tools: Cypress, Playwright, Selenium.
“Our E2E tests simulate a user registering, logging in, and completing a purchase.”
Slowest and most expensive to maintain, but catch the most realistic failures.
Smoke Test
A smoke test is a quick set of basic checks to verify the application starts and core functionality works. Run after a deployment to catch critical failures immediately.
“We always run smoke tests after deploying — if the login page loads and the database responds, we proceed.”
Regression Test
A regression test checks that a change has not broken existing functionality. When a bug is fixed, a regression test is written to ensure it does not come back.
“After refactoring the auth module, all regression tests passed.”
Performance Test
A performance test measures how the system behaves under load — response times, throughput, resource usage.
Variants: load test (normal expected load), stress test (beyond normal capacity), spike test (sudden traffic spikes).
Security Test
A security test looks for vulnerabilities in the application. Includes OWASP checks, penetration testing, and automated scanning.
Acceptance Test
An acceptance test verifies that a feature meets the business requirements and is ready to be accepted. Usually based on acceptance criteria written in user stories.
Test Doubles: Mock, Stub, Fake, Spy
These terms are often confused. They are all “test doubles” — replacements for real dependencies used in tests.
Mock
A mock is a test double that verifies behaviour — specifically that certain methods were called, with the right arguments, the right number of times. If the expected call does not happen, the test fails.
“I mocked the email service and verified it was called once with the correct recipient address.”
Stub
A stub is a test double that returns predetermined responses to method calls. It makes no assertions about how it is used — it just provides canned data.
“I stubbed the user repository to return a fixed user object — so the test doesn’t need a database.”
The key difference: Mocks verify calls were made. Stubs provide data.
Fake
A fake is a simplified but working implementation of a dependency — like an in-memory database instead of a real one, or an in-memory message queue. More complex than a stub but lighter than the real thing.
Spy
A spy is a test double that wraps a real object and records how it was used. Unlike a mock (which replaces entirely), a spy calls through to the real implementation by default.
Test Quality
Test Coverage (Code Coverage)
Test coverage measures what percentage of code is executed by tests. Usually broken down by:
- Line coverage — % of lines executed
- Branch coverage — % of branches (if/else paths) executed
“We have 80% line coverage — but there are uncovered branches in the error handling.”
High coverage is a goal, but 100% coverage does not mean the tests are good. Coverage measures quantity, not quality.
Assertion
An assertion is a statement in a test that checks an expected condition. If the assertion fails, the test fails.
assert result == 42orexpect(result).toBe(42)
Test Suite
A test suite is a collection of tests — can mean all tests in a file, a class, or the entire test project.
“The full test suite takes 12 minutes to run on CI.”
Flaky Test
A flaky test is a test that sometimes passes and sometimes fails without any code changes — usually due to timing issues, test order dependencies, or external service unreliability.
“That test is flaky — it fails about 1 in 10 runs on CI.”
Flaky tests erode trust in the test suite: when tests fail randomly, genuine failures get ignored.
Testing Approaches
TDD (Test-Driven Development)
TDD is a development practice where you write the test before the code:
- Write a failing test
- Write the minimum code to make it pass
- Refactor
The cycle is called Red–Green–Refactor.
BDD (Behaviour-Driven Development)
BDD is an extension of TDD where tests are written in plain language describing behaviour. Tests are structured as: Given [context] When [action] Then [expected result]. Tools: Cucumber, SpecFlow, Gherkin.
“Given the user is logged in, When they click ‘Export’, Then a CSV file is downloaded.”
ATDD (Acceptance Test-Driven Development)
ATDD involves writing acceptance tests before development begins, collaborating with product owners and stakeholders to define what “done” means.
CI/CD Testing Terms
Test Pipeline
The test pipeline is the automated sequence of tests run on every code commit or PR — usually: unit tests → integration tests → (E2E tests optional).
Test Runner
A test runner is the tool that finds and executes tests and reports results. Examples: Jest (JavaScript), pytest (Python), JUnit (Java), RSpec (Ruby).
Test Report
A test report summarises which tests passed, failed, or were skipped, along with timing and failure messages. Generated by the test runner, often published to CI dashboards.
Quick Reference
| Term | One-liner |
|---|---|
| Unit test | Tests one function/class in isolation |
| Integration test | Tests how components work together |
| E2E test | Tests full user flows end-to-end |
| Smoke test | Quick check that core functionality works after deploy |
| Regression test | Ensures a bug fix doesn’t reappear |
| Mock | Verifies that specific calls were made |
| Stub | Returns fixed data; no behaviour verification |
| Fake | Simplified but working implementation |
| Spy | Wraps real object; records calls |
| Flaky test | Fails non-deterministically |
| TDD | Write test first, then code |
| BDD | Tests describe behaviour in plain language |
| Coverage | % of code executed by tests |
Navigating the Nuances: Common Phrases in a Team Setting
Let’s be honest – understanding technical terminology is only half the battle. The real challenge for developers learning professional English often lies in how you communicate that knowledge within a team. It’s not just about knowing what “unit test” means; it’s about phrasing your feedback, explaining your approach, and collaborating effectively with colleagues who may have different backgrounds or levels of experience. Consider this: a senior developer reviewing your pull request might say, “This is good, but can you add some more assertive checks to these unit tests? We need to ensure the edge cases are covered thoroughly.” That phrase – “more assertive” – isn’t immediately obvious in its meaning; it implies needing greater confidence in the test’s ability to detect potential problems. Similarly, a Slack message asking for help could be phrased as “Can someone explain how to use jest’s mocking capabilities to isolate this component?” The word “capabilities” subtly shifts the conversation from simply using mocks to understanding their potential – it invites discussion about strategic application.
Another frequent situation involves explaining your testing strategy during a code review. Rather than saying, “I’m using stubs,” which can sound somewhat defensive, you might articulate: “To facilitate focused unit testing, I’ve employed stubs for the external dependencies, allowing me to verify that the core logic functions correctly in isolation.” Notice the more formal language here – it demonstrates a deeper understanding of the why behind the technique. This approach is particularly important when collaborating with international teams where direct translations might not capture the subtleties of English technical vocabulary. Being precise and choosing your words carefully can avoid misunderstandings and build trust within the development team. It’s also crucial to remember that asking clarifying questions – “Could you elaborate on what you mean by ‘robust’ in this context?” – is perfectly acceptable, demonstrating a willingness to learn and improve communication.
Finally, when writing PR descriptions, clarity is paramount. Avoid vague statements like “Testing completed.” Instead, try something more descriptive: “Implemented unit tests covering the core authentication flow using Jest mocking for the user database service. Test coverage currently stands at 85%.” This provides immediate context and demonstrates a level of detail that’s expected in professional settings. It also allows reviewers to quickly assess the scope of your testing efforts.
Here’s an example of how you might use jest to mock a dependency:
jest --env nodeargs --maxWorkers 1 --testEnvironment jsdom --coverageReporters cli --coveragePathMap ./coverage/pathmap.json --collectCoverageFrom="./src/**/*.js" --testName=myTestThis command uses jest’s powerful mocking capabilities to isolate a component for testing, focusing on its internal logic without relying on external dependencies. This is a key concept when discussing the strategic use of mocks and stubs.