Regression Testing vs Unit Testing

Regression testing and unit testing are not two options to pick between. Unit testing names a scope: one small piece of code, tested on its own. Regression testing names a purpose: finding out whether a change broke something that used to work. A unit test that you run again after a change is a regression test. For the layers around unit tests, see unit tests vs integration tests. This post covers how the two terms overlap and where a unit suite stops being enough.

Regression testing vs unit testing at a glance

A unit test asks “does this piece of code do the right thing?” A regression test asks “does this still work after the change?” The first question sets a scope. The second sets a reason for running the test.

	Unit test	Regression test
Defined by	Scope: one small piece of code	Purpose: catching breakage after a change
Question	Does this code do what I wrote?	Does what worked before still work?
Size	Low-level, a small part of the system	From one function to a full journey
Speed	Expected to run faster than other kinds of tests	Depends on what the suite holds
Runs	While coding, and again on every change	After a change, before a release

Diffblue draws the same line. Unit tests validate individual components or functions in isolation, and regression tests verify that the entire application continues to function correctly after changes. The two do not compete.

What a unit test is

A unit test checks one small piece of code, such as a function or a class, on its own. Martin Fowler’s note on unit tests says they are low-level and focus on a small part of the software system, and that they are expected to run faster than other kinds of tests.

That small scope is a strength. When a unit test fails, it names the function that broke, and nothing else was under test, so the failure has few suspects.

The scope is also the limit. A unit test stays inside the process. It does not start your server or send a real request, so it cannot see wiring, config or what a client reads back from a response.

What regression testing is

Regression testing is re-running tests to confirm that software which worked before still works after a change. The name describes the failure: something that used to work no longer does.

A regression suite is not a fixed list. Suites tend to grow with each defect that gets found, so test automation is frequently involved. Many projects have a continuous integration system that re-runs the regression tests at set intervals and reports failures. A failure can mean a real regression or an out-of-date test.

Large suites are often cut down. Teams sometimes run a change impact analysis to determine an appropriate subset of tests. The Wikipedia article on regression testing covers the techniques in more depth. For how an integration test differs from a smoke test, see smoke test vs integration test.

How they overlap

The two terms answer different questions, so one test can be described by both. A unit test is defined by what it covers. A regression test is defined by why you run it.

• A unit test that guards a fixed bug. Its scope is a unit, and its purpose is regression.
• A unit suite re-run by CI on every change. Its job is then regression: it reports whether an old behavior broke.
• A browser test of checkout, run before a release. Its scope is end-to-end, and its purpose is regression.

The overlap runs one way. Most unit tests can do regression work, but a regression suite is not made only of unit tests. Regression tests can verify that the entire application still works after a change. For where the wider layers start, see integration testing vs end-to-end testing.

Where unit tests fall short as a regression suite

A large unit suite guards logic well and wiring poorly. We tested that. The unit suite had 2,189 passing tests covering 99% of the lines in the app’s source. We ran both kinds of test against the same 8 bugs. The unit tests caught 5 of the 8 and one API flow test caught 6. Each caught bugs the other missed, and one bug got past both.

The clearest miss was a login token rename. The commit renamed the token and updated the unit tests that read it, so all 2,189 tests passed. The web app still read the old name, so nobody could log in. The tests agreed with the code. They did not agree with the client.

A big suite has a second cost. In our run it went red on three of four refactors that changed nothing a user or client sees. That teaches a team to update failing tests on sight, and the commits that hid the rename had updated their tests too. The full method is in our unit test experiment.

API flow tests as regression tests

An API flow test sends a sequence of real requests to your running app and checks each answer. Run on every pull request, it is a regression test at the API layer: it tells you whether a journey that worked before still works after the change. Functional, integration, contract, load and security checks are the usual types of API testing.

Stresseur records how an API is really used during development, turns those flows into YAML tests and runs them in CI on every pull request. The flows live in your repo under api-tests/. npx stresseur init-ci writes the GitHub Actions workflow. In CI the workflow runs each flow 13 times, 1 warm-up and 12 measured, and uploads per-step timings.

See API integration tests from real traffic for how it works, or run API tests on every pull request for the CI setup.

Regression testing is a purpose and unit testing is a scope, so the two are not rivals. Unit tests make fast, precise regression checks for logic. They miss breaks between the client and the server, and a few API flows cover those. Run both on every pull request, and read each test update before you accept it.