Skip to main content
Engineering LibreTexts

7.7: Regression Test After Every Change

  • Page ID
    32907
  • \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \) \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)\(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\) \(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\)\(\newcommand{\AA}{\unicode[.8,0]{x212B}}\)

    Intent Build confidence by making sure that whatever worked before still works.

    Problems

    How can you be sure that the last change you made won’t break the system?

    This problem is difficult because:

    • In a complex system, small changes can have unexpected side effects. A seemingly innocuous change may break something without this being immediately discovered.

    Yet, solving this problem is feasible because:

    • You have written test suites that express how the system should behave.

    Solution

    Run your regression test suite every time you think you have reached a stable state.

    Tradeoffs

    Pros

    • It is easier to Always Have a Running Version.

    • It is easier to Build Confidence as you proceed.

    Cons

    • You must relentlessly write the tests.

    Difficulties

    • The legacy system may not have adequate regression tests defined. To enable evolution, you will have to Grow Your Test Base Incrementally.
    • Tests can only show that defects are present, not that they are absent. You may have failed to test precisely the aspect that you have broken.

    • Run the tests may be very time-consuming, so you might want to run only those tests that you think might be affected by your change. Categorize your tests to avoid “ad hoc” testing of changes, but run all the tests at least once a day.

    Rationale

    Regression tests tell you that whatever ran before still runs. If you consistently build up tests for defects you discover and new features, you will end up with a reusable test base that gives you confidence that your changes are sound, and helps you detect problems earlier.

    Davis advocates “Regression Test After Every Change” [Dav95] as standard Software Development practice.

    Related Patterns

    You should have already started to Write Tests to Enable Evolution.

    A common practice in Extreme Programming is to write tests before you implement new functionality [JAH01]. In the context of reengineering, you should consider writing tests that will fail before you make a change, and will pass if the change is correctly implemented. (Unfortunately it is not generally possible to design tests that will only pass if the change is correct!)

    Regression tests should help you to Retest Persistent Problems.


    This page titled 7.7: Regression Test After Every Change is shared under a CC BY-SA license and was authored, remixed, and/or curated by Serge Demeyer, Stéphane Ducasse, Oscar Nierstrasz.

    • Was this article helpful?