liveBook · Manning

Regression

As explained in The Art of Unit Testing 3e

A previously working software behavior that becomes broken after a change.

A regression is functionality that used to work but is now broken after a change. It can affect a single unit of work or several previously working behaviors. section 1.8

Regressions are easy to miss when shared code or data changes over time. They often appear near a sprint or release deadline, when a fix for one bug accidentally introduces another. section 1.8

Use runnable tests as a safety net:

  • Run tests for earlier features after making a change, rather than assuming they still work. section 1.8
  • Make tests accessible so teammates can check whether a change broke code they depend on. section 1.8
  • Treat reliable test results as confidence to change unfamiliar or legacy code. section 1.8

How The Art of Unit Testing 3e covers it

How deep it goes
Defines regression plainly and explains its testing consequences, while deferring how rapid detection is implemented.
Examples
Uses deadline-driven bug fixes and changes to unfamiliar legacy code as regression-risk scenarios.
What it assumes
Teaches regression from a direct definition without stating required prior knowledge.
What you can do after
Evaluate/understand whether runnable tests provide confidence that a change preserved earlier functionality.
How it connects
Connects regressions with unit tests, integration tests, legacy code, shared data, and bug fixes.

Also explained in

Compare how 5 books explain regression →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of The Art of Unit Testing 3e. The section links point to the parts of the book it draws on.