English for Vitest Developers

Vitest has become the default unit testing framework for Vite-based JavaScript and TypeScript projects, and it comes with a vocabulary that non-native English speakers often find confusing. Words like “spy”, “stub”, and “mock” are all used in testing but mean different things. Knowing how to use these terms correctly helps you write clearer PR descriptions, contribute to technical discussions, and read Vitest documentation without guessing.

Key Vocabulary

Mock A complete replacement for a real module or function that you control entirely in tests. In Vitest, vi.mock('module-name') replaces the whole module with auto-generated stubs you can configure. Example: “I mocked the email service so the test doesn’t send real emails to customers.”

Spy A wrapper around a real function that tracks how it was called — arguments, call count, return values — without replacing its behaviour. Created with vi.spyOn(). Example: “I added a spy on console.error to assert the component logs the right message on failure.”

Stub A simplified stand-in for a function that returns a pre-defined value, used when you do not want the real implementation to run. In Vitest, vi.fn() creates a stub function you can configure with .mockReturnValue(). Example: “The stub returns an empty array so the component renders its empty-state UI during the test.”

Snapshot A saved serialisation of a value — often a component’s rendered output — that Vitest compares against on subsequent test runs. If the output changes, the test fails until you review and update the snapshot. Example: “The snapshot test caught an unexpected class name change in the button component.”

Coverage Threshold A minimum percentage of code that must be exercised by tests. If coverage drops below the threshold, the CI pipeline fails. Configured per metric: lines, functions, branches, statements. Example: “Our branch coverage threshold is 80% — the new utility function dropped us to 76%, so we need more tests.”

Describe Block A describe() call that groups related tests under a shared label. Nesting describe blocks creates a readable hierarchy that appears in the test output. Example: “I wrapped the validation tests in a describe block called ‘when the form is empty’ to make the output easier to read.”

beforeEach / afterEach Hook Functions that run before or after every test in a suite. Used to set up shared state or clean up side effects so tests remain independent. Example: “The beforeEach hook resets the store to its initial state so each test starts from a known baseline.”

vi.fn() Vitest’s function for creating a mock function from scratch. It tracks calls and can be configured to return specific values, throw errors, or run a custom implementation. Example: “I passed a vi.fn() as the onSubmit prop and then asserted it was called once with the correct payload.”

Common Phrases

In code reviews:

• “This test is using a real HTTP client — can we replace it with a mock so the test doesn’t hit the network?”
• “The spy here never gets reset between tests; add a vi.restoreAllMocks() call in afterEach to prevent state leaking.”
• “The snapshot is quite large — if it changes frequently it will create noise in PRs. Consider a more targeted assertion instead.”

In standups:

• “I’m writing unit tests for the auth utility — I’m mocking the token service and asserting the refresh logic in isolation.”
• “Coverage is at 73% — I need to add tests for the error branches before this PR is ready to merge.”
• “The beforeEach hooks were duplicated across three test files, so I extracted them into a shared setup helper.”

In documentation:

• “Use vi.spyOn() when you want to observe calls to a real function without replacing its implementation.”
• “Run vitest --coverage to generate a coverage report; the thresholds are configured in vite.config.ts under test.coverage.”
• “Snapshots are stored in __snapshots__/ next to the test file; commit them alongside the test that created them.”

Phrases to Avoid

Confusing “mock” and “spy” — Non-native speakers often use “mock” for everything. If the original function still runs but you are watching it, say “spy.” If you replaced the function entirely, say “mock.” Reviewers will notice the difference: “I mocked fetch” vs. “I spied on fetch” are not the same action.

Saying “the test is wrong” when you mean the snapshot needs updating — When a snapshot fails because of an intentional UI change, the correct phrase is “update the snapshot” or “the snapshot is outdated.” Saying the test is wrong implies a bug in the test itself.

Saying “empty test” — If a test has no assertions, the correct term is a “passing test with no assertions” — or more commonly, you would call it an “incomplete test” or note that it “lacks assertions.” A truly empty test file is called a “placeholder” or “stub test file.”

Quick Reference

Term	How to use it
mock	”We mock external dependencies to keep unit tests fast and deterministic.”
spy	”A spy lets us assert how many times a function was called.”
stub	”The stub always returns null to test the null-handling path.”
coverage threshold	”The pipeline enforces an 80% line coverage threshold.”
snapshot	”Run vitest -u to update all outdated snapshots at once.”

Beyond the Basics: Refining Your Professional Communication as a Vitest Developer

So far, we’ve covered the core concepts of Vitest – focusing on how to write effective tests using mocks, spies, snapshots, and understanding coverage reports. But let’s be honest, even with perfect test code, communication is key in any development environment. As a non-native English speaker, particularly when working with international teams or documenting your work for broader audiences, precise and professional phrasing can make a huge difference. It’s not just about understanding the technical terms; it’s about conveying your ideas clearly and confidently.

One common area of friction is code review comments. Receiving feedback like “This needs more coverage” or “Consider using a mock for this dependency” can be daunting, especially if you’re struggling to articulate your reasoning or understand the reviewer’s expectations. Instead of simply accepting the comment, try framing your response with clear and detailed explanations. For instance, saying “I appreciate the feedback on coverage. I was initially focused on verifying the core logic but will investigate adding a test case for [specific functionality] to address this concern.” demonstrates engagement and willingness to collaborate. Similarly, when describing a PR’s purpose, use language that highlights why changes were made – “This PR refactors the data fetching component to improve performance and readability, addressing identified bottlenecks in the original implementation.” Avoid jargon where possible, or explain it clearly if necessary.

Another frequent scenario involves discussions about snapshot failures. Receiving an email stating “Snapshot mismatch detected” isn’t just a technical notification; it’s an invitation for clarification. Rather than reacting defensively, acknowledge the issue and request more information: “Could you please provide the output of the failed snapshot run? It would be helpful to understand the differences between the expected and actual states.” This shows initiative and a desire to quickly resolve the problem. Remember, clear communication builds trust and facilitates efficient collaboration. Focusing on what needs to change and why is far more impactful than simply stating that something “doesn’t match.”

Finally, let’s consider how you describe your tests in PR descriptions. A good description should concisely outline the purpose of each test and its expected behavior. Don’t just list the tests; explain their intent. “Tests verify the correct calculation of [metric] based on provided input data.” This provides context for reviewers and helps them quickly understand the scope of your testing efforts.

Here’s a simple example using vitest to demonstrate a common scenario:

# Running a snapshot test with Vitest
vitest run --ui

This command, when used in conjunction with properly crafted tests, allows you to quickly identify discrepancies between expected and actual states of your application. Focusing on clear communication around these tools and their outputs will significantly enhance your effectiveness as a Vitest developer and contribute to a smoother workflow within your team.