This guide shows you how to install and configure a complete testing toolchain for a software project: a unit testing framework, a mocking library, a code coverage reporter, and an automated test script that can run in continuous integration. By the end, you will be able to run a single command that executes your test suite, reports pass/fail status, and prints a coverage summary.
Get business pricing on monitors, keyboards and dev gear
- Business-only prices and quantity discounts
- Tax-exempt purchasing
- Multiple users, one account, clear invoices
How Google Tests Software
- ✔ Format: Print / ebook
- ✔ Topic: Software testing and quality assurance at scale
- ✔ Publisher: Addison-Wesley
Full Stack Testing: A Practical Guide for Delivering High Quality Software
- ✔ Format: Print / ebook
- ✔ Publisher: O’Reilly Media
- ✔ Topic: Full stack software testing
Software Engineering at Google: Lessons Learned from Programming Over Time
- ✔ Format: Print / ebook
- ✔ Publisher: O’Reilly Media
- ✔ Topic: Software engineering practices at scale
This guide is written for developers who already have a working codebase in a language such as JavaScript/TypeScript, Python, or Java, and who want to add testing infrastructure from scratch. It is aimed at an intermediate level: you should be comfortable installing packages and running commands in a terminal, but no prior testing experience is required. Examples are given for JavaScript (Vitest/Jest) and Python (pytest), with notes on how the same steps map to other stacks.
Expect to spend one to two hours, most of it on installation and writing your first few tests. Once the toolchain works, adding tests becomes fast and routine.
Difficulty: Intermediate | Time: 1-2 hours
What You’ll Need
Tools & Materials:
- A codebase you can modify, with source code organized into files or modules
- A package manager (npm, yarn, pip, or the equivalent for your language)
- A terminal and a code editor
- Git (recommended, so configuration changes can be committed safely)
Knowledge:
- Basic command-line usage
- How to install dependencies in your language’s package manager
- Familiarity with the structure of your own codebase (where functions and modules live)
Back up or commit your current work before installing anything. Test frameworks add configuration files and dependencies; committing first means you can always roll back if installation conflicts with an existing setup. If your project already has a test framework installed, do not install a second one — work with the existing tool instead to avoid duplicate runners and conflicting configs.
How Google Tests Software
This book occupies a unique position in our lineup: it is the only one focused squarely on how testing is organized rather than how tests are written. Written from inside Google, it walks through the company’s division of roles — the SETs and TEs who made quality everyone’s job — and explains how testing scales across codebases that most teams will never encounter. For a technical lead asking "how should my organization think about testing?", this remains the most candid account available.Compared with Software Engineering at Google, this title goes deeper on testing specifically, covering the tooling and processes around test automation, risk analysis, and large-scale change management. The tradeoff is age: Google’s practices have evolved considerably since publication, and some of the internal tools described no longer reflect current reality. Where Full Stack Testing gives you modern, hands-on techniques, this book gives you a mental model — one that has influenced testing culture across the entire industry.Readers at small companies should calibrate expectations. The book itself acknowledges that its practices were built for enormous teams, and transplanting them wholesale into a ten-person startup will feel like overkill. The value here is in the principles and role design, not copy-paste process.
Pros:
- Rare insider perspective on testing at one of the world’s largest engineering organizations
- Covers organizational culture and role design, not just technical tooling
- Explains how testing scales across massive codebases and teams
- Influential enough that its vocabulary is now industry standard
Cons:
- Practices have evolved at Google since publication, so some content feels dated
- Approaches assume large-team resources that smaller companies lack
- Lighter on hands-on, copy-today test code than practical guides
Best for: Engineering leads and QA managers who want to understand how testing scales in large organizations
Not ideal for: Solo developers or small startups needing immediately applicable testing techniques
Bottom line: Still the definitive read on how a hyperscale company organizes software testing, best treated as a source of principles rather than a current playbook.
“Still the definitive read on how a hyperscale company organizes software testing, best treated as a source of principles rather than a current playbook.”
Full Stack Testing: A Practical Guide for Delivering High Quality Software
We placed this O’Reilly title at the top of the list because it does what most developers actually need: it walks through testing across the entire software stack — from unit and integration tests through UI, API, performance, and production quality — with concrete, usable guidance. Where How Google Tests Software describes how one enormous company solves the problem, this book meets you at your own codebase and shows you what to do about it.This option stands out for its practical, hands-on framing. Rather than arguing for a particular philosophy, it covers the modern quality landscape: test automation strategy, CI/CD integration, non-functional testing, and how to prioritize what to test when time is short. Compared with Software Engineering at Google, which dedicates only part of its篇幅 to quality, this book stays on topic from first page to last, making it the more efficient purchase if testing is your immediate concern.The main tradeoff is breadth of context. It will not teach you how to redesign your organization’s engineering culture or staff a QA function — that is the Google books’ territory. And because it spans the full stack, individual chapters on specialized areas necessarily go less deep than dedicated single-topic books. For most developers and QA engineers, though, that breadth is exactly the point.
Pros:
- Comprehensive coverage across unit, integration, UI, API, and non-functional testing
- Practical guidance oriented toward real delivery timelines
- Written for developers, QA engineers, and technical leads alike
- Published by O’Reilly, known for technically rigorous practitioner titles
Cons:
- Spans so much territory that no single topic gets exhaustive depth
- Less useful for shaping organization-wide testing culture
- Assumes some baseline familiarity with software development workflows
Best for: Developers and QA engineers who want actionable, modern testing strategies they can apply immediately
Not ideal for: Engineering leaders focused primarily on organizational process and culture design
Bottom line: The most immediately useful pick in this lineup — a modern, stack-wide testing guide that working developers can put into practice right away.
“The most immediately useful pick in this lineup — a modern, stack-wide testing guide that working developers can put into practice right away.”
Software Engineering at Google: Lessons Learned from Programming Over Time
If our top pick is a specialist and How Google Tests Software is a testing biography, this book is the big-picture companion: a sweeping account of how Google builds and maintains software over decades, written by the engineers who did it. Testing and quality appear throughout — test sizes, test coverage philosophy, flaky test management, code review, and maintainability — but always framed inside a larger engineering system. That framing is its greatest strength and its clearest limitation.Compared with How Google Tests Software, this is the more modern and more comprehensive volume, and its chapters on testing-adjacent topics like static analysis, dependency management, and large-scale change explain why Google’s testing practices work, not just what they are. If you buy only one Google book, this broader one arguably offers more lasting value. But if testing is your burning question, Full Stack Testing will get you there faster and with more directly applicable techniques.This pick makes the most sense for senior engineers and architects who think in terms of decades, not sprints. The material is honest about tradeoffs — time versus maintainability, speed versus stability — and that candor is rare in engineering writing. Smaller teams should be prepared to translate aggressively rather than adopt wholesale.
Pros:
- The most current and comprehensive look at Google’s engineering practices in this lineup
- Written by experienced Google engineers with decades of accumulated lessons
- Treats testing as part of a broader system including code review, testing culture, and maintainability
- Explains the reasoning behind practices, not just the practices themselves
Cons:
- Testing is one topic among many, so coverage is less focused than a dedicated testing book
- Oriented toward large-scale engineering that may not map to small teams
- Its sheer breadth makes it a slower, more committed read
Best for: Senior engineers and technical leads who want testing framed within sustainable, long-term engineering practice
Not ideal for: Startups and small teams needing lean, immediately applicable testing recipes
Bottom line: A wide-lens engineering book that contextualizes testing within sustainable practice — the right choice when you want the why behind the what.
“A wide-lens engineering book that contextualizes testing within sustainable practice — the right choice when you want the why behind the what.”
As an Amazon Associate we earn from qualifying purchases.
Before You Start
Three decisions shape everything that follows. First, pick one test framework that matches your stack: Vitest or Jest for JavaScript/TypeScript, pytest for Python, JUnit for Java, and PHPUnit for PHP. Mixing frameworks is the most common cause of confusing setups. Second, confirm your package manager version is current (npm --version, pip --version) — old versions can fail silently on newer packages. Third, check whether your project already has a test script in its package.json, Makefile, or CI config; if so, extend that script rather than replacing it, so existing workflows keep working.
Step-by-Step Instructions
Step 1: Install the test framework
Open a terminal in your project root and install the framework as a development dependency. For a JavaScript project, run npm install -D vitest. For a Python project, run pip install pytest (or better, add it to your project’s requirements or virtual environment first, then install). Wait for the install to finish without errors before moving on.
Tip: Use the -D flag (or your language’s equivalent for dev-only dependencies) so the test framework is not shipped to production builds. In Python, keep pytest out of your runtime requirements file and in a separate dev requirements file.Check: Running npx vitest --version or pytest --version prints a version number with no errors.
Step 2: Install the mocking library
Install the mocking tool that pairs with your framework. Vitest and Jest include built-in mocking (vi.mock() / jest.mock()), so no extra install is needed for JavaScript. For Python, run pip install pytest-mock, which provides the mocker fixture. For Java, Mockito is standard: add it alongside JUnit in your build file.
Tip: Do not install a standalone mocking library for JavaScript unless you have a specific reason — the built-in mock functions cover network calls, timers, and module replacement, and extra libraries usually add configuration conflicts.
Check: Importing or referencing the mock function in a scratch test file does not throw an import error.
Step 3: Create a test directory and config file
Create a dedicated tests/ directory at the project root (or follow your framework’s convention, such as __tests__/ for Vitest/Jest). Then create the configuration file: vitest.config.ts for Vitest, pytest.ini or pyproject.toml settings for pytest. In the config, specify where tests live and which files count as tests, for example matching tests/**/*.test.ts or test_*.py.
Tip: Keep test files in one predictable location rather than scattered next to source files while you are learning. It makes the runner faster to configure and makes it obvious when a test file is accidentally skipped.
Check: Running npx vitest or pytest from the project root finds zero test files but exits cleanly — it should not say ‘no configuration found’.
Step 4: Write your first passing test
Pick the simplest pure function in your codebase (something like a formatting helper or calculation function) and write one test for it in the test directory. In Vitest, this looks like:
import { describe, it, expect } from 'vitest'; import { formatPrice } from '../src/utils'; describe('formatPrice', () => { it('formats cents to currency', () => { expect(formatPrice(1999)).toBe('$19.99'); }); });
In pytest: from src.utils import format_price; def test_format_price(): assert format_price(1999) == '$19.99'.
Write the test to match what the function actually does — verify by calling it manually if unsure — so your first test passes.
Tip: Start with a deliberately passing test. If your first test fails, you cannot tell whether the problem is your test code, your config, or the function itself. Prove the pipeline works first, then test real behavior.
Check: The test runner reports 1 passed, 0 failed.
Step 5: Write a test with a mock
Write a second test that exercises a function with an external dependency — a network call, database query, or current time — and mock that dependency so the test runs offline and deterministically. In Vitest, use vi.mock('./api', () => ({ fetchData: vi.fn().mockResolvedValue({ id: 1 }) })) and then assert on the mocked result. In pytest with pytest-mock, use mocker.patch('src.api.fetch_data', return_value={'id': 1}).
Tip: Mock the boundary of your system (the API client module), never deep internals. Mocking internals makes tests brittle: every refactor breaks the mock even when behavior is unchanged.
Check: The test passes and completes in under a second, with no network activity required — disconnect from the network and rerun to confirm.
Step 6: Add coverage reporting
Enable code coverage so you can see which parts of the codebase your tests exercise. Vitest includes it via the --coverage flag with @vitest/coverage-v8 installed (npm install -D @vitest/coverage-v8). For pytest, run pip install pytest-cov and use pytest --cov=src. Run the suite with coverage enabled and read the printed table showing coverage percentage per file.
Tip: Treat coverage as information, not a target. A 100% coverage number with weak assertions is worse than 60% coverage with meaningful tests. Do not write tests purely to raise the number.
Check: The command prints a coverage table listing your source files with percentage values, and exits successfully.
Step 7: Add a single test script
Define one command that runs the full suite with coverage. In package.json, add "scripts": { "test": "vitest run --coverage" }. For Python, add a Makefile target or shell script running pytest --cov=src. The word ‘run’ after vitest matters — without it, vitest enters watch mode and never exits, which breaks CI.
Check: Running npm test (or make test) executes all tests once, prints coverage, and returns control to the terminal.
Step 8: Wire the script into CI
If you use GitHub Actions, create .github/workflows/test.yml containing a job that checks out the code, installs dependencies, and runs your test script. Other CI platforms (GitLab CI, CircleCI) follow the same pattern: install, then run the test command. Commit the workflow file and push.
Tip: Pin the CI run to a single stable language version at first. Version mismatches between your machine and CI are the leading cause of ‘works locally, fails in CI’ problems.
Check: Within a few minutes of pushing, the CI platform’s web interface shows a green check mark on the commit with a test-run log you can open.
Step 9: Verify the failure path
Temporarily break your first test (change the expected value), run the suite locally, and confirm it exits with a failure and a non-zero status. Then push and confirm CI shows a red mark. Revert the change and confirm everything goes green again.
Tip: This step is frequently skipped and it is the one that proves your toolchain actually catches bugs. A test setup that silently passes everything is worse than no tests.
Check: Local run fails with a clear assertion message when the test is broken, and passes again after reverting; CI reflects both states correctly.
Common Mistakes to Avoid
- Installing two test frameworks (for example, both Jest and Vitest) in the same project. — Check package.json and existing config files before installing. Pick one framework, remove the other completely, including its config and transformers.
- Mocking deep internals of the code instead of external boundaries, producing tests that break on every refactor. — Mock only modules at the edge of your system: API clients, database drivers, clocks, and file system wrappers. Test internal logic through its public functions.
- Leaving the test runner in watch mode in the CI script, so builds hang and time out. — Use the non-watch invocation (e.g.,
vitest run) in any script intended for automation. Reserve watch mode for local development only. - Writing the first test against a complex, dependency-heavy function, so a failure gives no clue whether the framework, config, or code is at fault. — Always validate the pipeline with one trivial passing test on a pure function before testing anything complicated.
Troubleshooting
Problem: Test runner reports ‘no test files found’ even though you created tests.
Solution: Check that your file names match the configured pattern exactly (e.g., .test.ts suffix or test_ prefix), and that the config’s include path matches your directory layout. Run the runner with verbose output to see which paths it scanned.
Problem: Import errors when tests try to load your source modules.
Solution: The test runner usually needs a path alias or module resolution setting matching your build setup. Add the same aliases to vitest.config.ts, or in pytest add an empty conftest.py at the project root so tests can import the package.
Problem: Tests pass locally but fail in CI.
Solution: Compare language and dependency versions between your machine and CI. Print versions in the CI job (node --version or python --version) and pin them in the workflow file to match your local environment exactly.
Problem: Flaky tests that pass and fail intermittently.
Solution: Search the failing tests for real network calls, random data, current time, or ordering dependencies — anything not mocked or seeded. Replace these with mocks or fixed test fixtures, and rerun the suite several times to confirm stability.
What Success Looks Like
Your setup is complete when all of the following hold: a single command (such as npm test or make test) runs the full suite once and exits; the output shows at least two passing tests including one that uses a mock; a coverage table prints with percentages per source file; the same command succeeds in CI and produces a green check mark on your commit; and deliberately breaking a test produces a red mark both locally and in CI. If all five conditions are true, your testing toolchain is working end to end.
Next Steps
With the toolchain in place, the next work is building the habit and the suite. Add a test for every new bug before you fix it — reproduce the bug in a failing test, fix the code, and keep the test as a regression guard. Prioritize testing pure business logic and boundary modules first, since they give the most value for the least mocking effort. Consider adding a linting or type-checking step to the same CI job so a single pipeline validates everything. Set a modest coverage baseline in CI once your suite grows, and raise it gradually rather than chasing a high number immediately. If tests become slow, split the suite into fast unit tests and slower integration tests so developers run the fast set on every change.
Frequently Asked Questions
Should I choose Vitest or Jest for a JavaScript project?
Use Vitest for new projects using Vite, TypeScript, or modern build tooling — it is faster and needs almost no configuration. Use Jest if your project already uses it, if you depend on Jest-specific libraries, or if your team knows it well. Both have identical mocking APIs for most cases, so switching later is not catastrophic.
How many tests do I need before this setup is worthwhile?
The toolchain pays for itself with even a handful of tests, because it gives you a one-command safety check and CI validation on every push. A practical early goal is one test per pure function in your core logic, then expand outward to functions with external dependencies.
Do I need a separate tool for integration or end-to-end tests?
Not at first. Start with unit tests using mocks. When you need to verify components working together, add integration tests in the same framework, running against a local database or test server. Only add a dedicated end-to-end tool like Playwright or Cypress when you need to test through the real UI.
What coverage percentage should I aim for?
There is no universal number. A common practical target is 70-80% on core business logic, tracked as a trend rather than a gate. High coverage on trivial code adds no value, while uncovered complex logic is a genuine risk — read the per-file table, not just the headline figure.
How do I test code that talks to a real database?
Unit tests should mock or fake the database layer so they stay fast and isolated. For verifying actual queries, write a small number of integration tests that run against a disposable database (an in-memory SQLite instance or a container started by CI), and mark them separately from unit tests so you can run them on demand rather than on every save.
Fall Picks
fall essentials
As an affiliate, we earn on qualifying purchases.
