Guide

What Is Unit Testing? How It Works, Types, and Where It Fits in 2026

Unit testing verifies the smallest pieces of your code, single functions or methods, in isolation, so you catch logic bugs in milliseconds. Here's how it works, the frameworks to use, and where unit tests stop and end-to-end testing has to take over.

Adithya Aggarwal

CTO & Co-founder at Pie

11 min read

Posted Jun 9, 2026

What Is Unit Testing?

Unit testing is the practice of verifying the smallest testable pieces of an application, usually a single function, method, or class, in isolation from the rest of the system. A unit test feeds the unit specific inputs, asserts that it produces the expected output or behavior, and runs in milliseconds, so a developer learns immediately whether one piece of logic is correct.

The defining trait is isolation. A unit test should exercise only the unit’s own logic, with its dependencies replaced by controlled substitutes. Michael Feathers, in his widely cited rules for unit tests, put it bluntly: “A test is not a unit test if it talks to the database, it communicates across the network, it touches the file system, [or] it can’t run at the same time as any of your other unit tests.” A test that does those things is valuable, but it is an integration test, and it belongs at a different layer.

Unit testing sits at the base of the test pyramid, the model popularized by Mike Cohn and Martin Fowler, with many fast, cheap unit tests at the bottom and fewer slow end-to-end tests at the top. The pyramid shape exists because unit tests are the cheapest tests to write and run, so it makes sense to have the most of them.

How Does Unit Testing Work?

A unit test works by following a simple, repeatable structure often called Arrange-Act-Assert. You arrange the inputs and setup, act by calling the unit under test, then assert that the result matches what you expected. The test runner executes hundreds or thousands of these in sequence and reports each as pass or fail, usually in a few seconds total.

Consider a function applyDiscount(price, percent). A unit test arranges the inputs (price = 100, percent = 20), acts by calling the function, and asserts the result equals 80. A good suite adds tests for the edge cases: a 0% discount, a 100% discount, a negative percent that should throw an error, a price of zero. Each of these is a separate test exercising one path through the same small piece of logic.

Because the function touches nothing external, the test is deterministic, producing the same result every run. That determinism is what makes unit tests trustworthy enough to gate a build, and it is the property that erodes fastest when tests reach beyond the unit. Once a test depends on a real clock, a network call, or shared state, it becomes a candidate for flakiness, the intermittent failures that quietly destroy a team’s faith in its suite.

Mocks, Stubs, and What Counts as a Unit

To keep a unit isolated, you replace its real dependencies with test doubles, stand-in objects that behave predictably. The two most common are stubs and mocks. A stub returns canned data, like a fake user repository that always returns the same user record, so the unit under test never touches a real database. A mock goes further and verifies interactions, asserting that the unit called the dependency with the right arguments the right number of times. Martin Fowler’s essay Mocks Aren’t Stubs remains the definitive treatment of the distinction.

Test doubles are what make the “milliseconds, deterministic” promise possible. A real database call might take 50 milliseconds and fail when the database is down. A stub returns instantly and never fails for an unrelated reason. The cost is that mocks encode an assumption about how the dependency behaves, and if that assumption drifts from reality, the unit test stays green while production breaks.

What counts as a “unit” is deliberately pragmatic. In functional code, a unit is usually a single function. In object-oriented code, it is often a single class with its collaborators mocked. The boundary matters less than the principle. A unit test should fail for exactly one reason, so that a red test points to one place in the code.

What Are the Most Popular Unit Testing Frameworks?

Every major language ships or supports a mature unit testing framework, and they share a common shape: a way to declare test cases, an assertion library to express expected outcomes, and a runner that executes tests and reports results. The framework you use is dictated almost entirely by your language, not by preference.

The lineage traces back to JUnit, the Java framework Kent Beck and Erich Gamma built in the late 1990s, which became the template nearly every later framework copied. Google’s testing team has noted that small, fast unit tests should make up the large majority of a healthy suite, roughly 70%, precisely because these frameworks make them so cheap to write and run.

Unit vs Integration vs End-to-End Testing

Unit, integration, and end-to-end testing answer three different questions, and confusing them is the most common reason a suite gives false confidence. Unit testing asks “does this piece of code work in isolation?” Integration testing asks “do these pieces work together with their real dependencies?” End-to-end testing asks “does the whole product work for a real user, from the UI down?”

Each layer trades speed for realism. Unit tests are the fastest and most precise, since a red test points to one function, but they prove nothing about how components interact. End-to-end tests are the slowest and flakiest, but they are the only layer that exercises what a user actually experiences. A mature strategy needs all three. The mistake is leaning on one to do another’s job, like trying to catch a broken checkout flow with unit tests alone.

How to Write a Good Unit Test (Step by Step)

Writing a good unit test is less about the framework and more about discipline: one behavior per test, clear inputs, a single meaningful assertion. The widely referenced FIRST principles (Fast, Isolated, Repeatable, Self-validating, Timely) capture the qualities that separate a unit test you trust from one you eventually delete. Here is a practical sequence.

1. Pick one behavior. A unit test should verify a single behavior of a single unit. If you find yourself asserting five unrelated things, that is five tests, not one. A focused test fails for exactly one reason.

2. Arrange, Act, Assert. Structure the body in three clear blocks: set up the inputs and doubles, call the unit once, then assert on the result. The visual separation makes the test readable months later.

3. Cover the edges, not just the happy path. The bug usually lives in the boundary case: the empty list, the null input, the off-by-one, the value that should throw. List the edge cases before you write the assertions.

4. Mock only what you must. Replace slow or unpredictable dependencies, like databases, network, and the clock, with stubs or mocks. Over-mocking couples the test to the implementation and makes refactoring painful, so mock at the boundary, not inside your own logic.

5. Keep it deterministic. A test that depends on real time, random values, or execution order will eventually flake. Inject the clock, seed the randomness, and isolate shared state. Test isolation at the unit level is what keeps the whole suite trustworthy.

6. Don’t chase a coverage number. Code coverage tells you which lines ran, not whether they were verified. A test that calls a function but asserts nothing meaningful inflates coverage while catching nothing. Aim for thorough tests on critical logic over a percentage on the dashboard.

Where Unit Testing Stops and Autonomous E2E Begins

Unit testing is essential and irreplaceable, but it has a hard ceiling, and pretending otherwise is how broken software ships with a green build. By design, a unit test verifies code in isolation with its dependencies mocked. It cannot, even in principle, catch a bug that lives in the interaction between units, in the UI, or in the real path a user takes through your product. A payment function can pass every unit test while checkout is broken, because the failure is in the wiring, not the function.

The inverted-confidence trap explains why. The cheaper and faster a test is, the less of the real system it touches. Teams over-invest at the base because unit tests are easy, hit high coverage numbers, and mistake that for product quality. Then a UI redesign, a third-party API change, or a device-specific rendering bug slips straight through, because no unit test was ever looking at the assembled product. Coverage of code is not coverage of behavior.

The honest answer is that you need the top of the pyramid too, and that is exactly where traditional tooling gets expensive. End-to-end tests are slow to write, brittle when selectors change, and a maintenance sink, which is why most teams under-build the layer that catches the bugs users actually hit. Autonomous QA platforms like Pie have been built to close that gap. Instead of hand-written, selector-based E2E scripts, Pie’s self-healing tests drive your real app the way a user would, locating elements by what they look like and do, and adapting automatically when the UI changes. It reaches the layer your unit tests structurally cannot, without the maintenance tax that normally makes teams skip it. It is how a team like Fi ships same-day releases, with unit tests guarding the logic and autonomous QA guarding the flows.

Build the Base, Then Cover What It Misses

Unit testing earns its place at the foundation of every serious test strategy. It is fast, precise, cheap, and it catches logic bugs the instant they are introduced. No amount of higher-level testing replaces a solid base of unit tests, and any team shipping without them is paying for it in debugging time they don’t see.

But a foundation is not a building. Unit tests prove your pieces work; they say nothing about whether the assembled product works for the person using it. The teams that ship confidently are the ones that build the base and cover what it misses, the integration seams and the real user flows, without drowning in test maintenance. Get the unit layer right, then let autonomous testing handle the layer it was never designed to reach.

Adithya Aggarwal

CTO & Co-founder at Pie

Eight years building search and delivery systems at Amazon. The kind of scale where flaky tests block billion-dollar releases. Now CTO at Pie, building AI agents that adapt when your UI changes. LinkedIn →