---
title: "Regression testing"
description: "Regression testing checks that new code changes have not broken previously working features. Learn regression types, automation and its place in CI/CD."
url: "https://nodea.io/en/glossary/regression-testing"
lang: "en"
updated: "2026-07-13"
---

# Regression testing

> Regression testing is the repeated running of tests to confirm that recent changes to the code — new features, bug fixes, refactoring — have not broken functionality that worked correctly before.

**Regression testing** is the repeated execution of tests to confirm that a modification to software has not caused a **regression** — that is, the reappearance of a bug or the breaking of a feature that previously worked. The name describes not a technique for writing a test, but the reason for running it: making sure new changes have not damaged an existing part of the system.

## How regression testing works

Every time a new feature, a fix or a [refactor](https://nodea.io/en/glossary/refactoring) lands in the code, there is a risk it will break a seemingly unrelated element — because they share a function, data or application state. To catch this, previously written [unit tests](https://nodea.io/en/glossary/unit-testing), [integration tests](https://nodea.io/en/glossary/integration-testing) and [end-to-end tests](https://nodea.io/en/glossary/e2e-testing) are run again. When a test that used to pass suddenly turns red, that signals a regression to fix before deployment. On large projects the full suite can take hours, so teams apply test selection (running only the tests related to the change) and prioritisation. A separate case is *visual regression*, where screenshots of the interface are compared to detect unintended changes in appearance.

## Practical application

Regression testing only makes sense when it is automated and run consistently — manually repeating hundreds of scenarios after every change is impossible. That is why it is wired into the [CI/CD](https://nodea.io/en/glossary/ci-cd) pipeline: each commit automatically fires the whole suite, and a failing test blocks the release. A good practice is the rule that whenever a new [bug](https://nodea.io/en/glossary/bug) is found, you first write a test that reproduces it and only then the fix — so the same bug never returns unnoticed. As a result, a growing regression pack acts as a safety net that lets the team change code confidently without fear of breaking working features.

### How does a regression test differ from a unit test?

They describe two different dimensions. A unit test defines scope — it checks a single piece of code. Regression testing defines intent — re-running existing tests to catch a regression. In practice the same suite of unit and integration tests, run after every change, serves as the regression pack.

## Related

- [Unit testing](https://nodea.io/en/glossary/unit-testing)
- [Integration testing](https://nodea.io/en/glossary/integration-testing)
- [CI/CD](https://nodea.io/en/glossary/ci-cd)
- [E2E (end-to-end testing)](https://nodea.io/en/glossary/e2e-testing)
- [Refactoring](https://nodea.io/en/glossary/refactoring)

---

Languages: [pl](https://nodea.pl/pl/slownik-pojec/testy-regresyjne.md)  
Site index: [llms.txt](https://nodea.io/en/llms.txt)