# What is regression testing? Source: https://www.plutonapps.com/resources/what-is-regression-testing Published 2026-09-30, updated 2026-10-24, sources checked 2026-10-24. By Irfan Habib (https://www.plutonapps.com/authors/irfan-habib). **Regression testing:** Regression testing is re-running a suite of existing automated tests after every change to an app, to confirm that features which already worked still work and that a fix in one place has not broken another. A regression is something that used to work and broke. Also known as: Regression tests. For the founder whose fix for one thing broke another. Here is the practice that stops it happening twice. ## Why does an app regress when each AI fix looks fine? Prompting an AI builder to fix one thing can change code far from where you were looking, and nobody checks the rest. That is how an app slowly gets worse while every individual change looked fine. Regression tests are the memory of everything that is supposed to keep working. ## Which kinds of regression testing are worth knowing? Three kinds are worth knowing: functional regression, automated tests of behavior run on every change; visual regression, which compares screenshots before and after to catch layout breaks; and bug regression, where every fixed bug gets a test so it cannot come back. Each one catches a different kind of breakage. - Functional regression: automated tests of behavior, run on every change. - Visual regression: screenshots compared before and after, to catch layout breaks. - Bug regression: every fixed bug gets a test, so it cannot come back. ## How does a regression suite catch a broken change? A regression suite catches a broken change by running automatically on every change, before it merges. Martin Fowler calls this self-testing code: one command runs the whole suite, and if it passes you can be confident the code has no substantial defects. In continuous integration, any failing test fails the build, so the change stops there. A concrete example: a founder asks an AI builder to rename a pricing tier, and the edit also changes how the checkout reads plan names. Nobody looks at checkout that day. A regression test that buys each plan in a test environment fails on that change, and the broken checkout never reaches a customer. ## How do you build regression tests for a Lovable app? Get the code into a repository through Lovable's GitHub integration, cover the paths that earn money first, turn every fixed bug into a test, and make a failing test block the release in your pipeline. Those four steps give a Lovable app a regression suite that runs on every change. 1. **Get the code into a repository** Lovable's GitHub integration syncs every version to a branch, which is where tests can run on each change. 2. **Cover the paths that earn money first** Sign-up, sign-in, checkout and the core feature. A few [end-to-end tests](https://www.plutonapps.com/resources/what-is-end-to-end-testing) check these journeys; faster unit tests cover the detail. 3. **Turn every bug into a test** Fowler's advice is to write a test that exposes a bug before fixing it, so the same bug cannot return unnoticed. 4. **Run the suite in the pipeline** Make a failing test block the release in your [CI/CD pipeline](https://www.plutonapps.com/resources/what-is-ci-cd). The common mistake is relying only on slow browser tests. Fowler's test pyramid notes that tests run through the user interface are slow, brittle and prone to failing at random, which erodes trust in them. Keep most regression tests small and fast. Our [production readiness check](https://www.plutonapps.com/tools/production-readiness-check) asks whether your app has them. In our process, every version you send from Lovable passes AI and human testing, including regression and visual regression, before it ships. > **What we see in practice** On [Looph](https://www.plutonapps.com/work/looph) the automated suite grew from 1,152 tests at handover to 10,387 passing in CI. ## Frequently asked questions ### Can regression testing be automated? Mostly, and it should be. Automated suites run on every change in minutes, so people can test what is new rather than re-checking what is old by hand. On Looph the automated suite grew from 1,152 tests at handover to 10,387 passing in CI. ### What is the difference between regression testing and smoke testing? A smoke test is a quick check that the most important paths work at all, often run right after a deploy. Regression testing is the broader suite that checks everything that worked before still does, and it includes a test for every bug that has been fixed. ### When should regression tests run? On every change, before it merges or ships. In continuous integration, each push to the shared branch triggers a build that runs the suite, and any failing test fails the build. Running it only before big releases lets broken changes pile up and makes the cause harder to find. ## Read next - [The Looph case study: from 1,152 tests to 10,387](https://www.plutonapps.com/work/looph) - [What the plans include](https://www.plutonapps.com/pricing) ## Sources - [Martin Fowler: Continuous Integration](https://martinfowler.com/articles/continuousIntegration.html) - [Martin Fowler: Self Testing Code](https://martinfowler.com/bliki/SelfTestingCode.html) - [Martin Fowler: Test Pyramid (May 1, 2012)](https://martinfowler.com/bliki/TestPyramid.html) - [Lovable documentation: GitHub integration](https://docs.lovable.dev/integrations/github)