40

In my job all developers that resolve a bug have to add a new unit test that warns about this type of bugs (in the case it occours again). If a unit test is not possible (for example, a webpage design issue), then QA department has to create a test case to manually check it.

The idea behind this is that if a defect has not been detected before the product release is because there isn't an appropriate unit test to detect it. So the developer has to add it.

The question is: is this common in any software development methodology? This technique has a name? I would like to learn more about it, but I need some information to start with it.

Improve this question
6
  • 6
    It's called regression testing and is quite common. I can only link a wikipedia article but it's far from perfect.
    – devmiles.com
    Feb 29, 2012 at 16:32
  • 25
    It is best practice to do this and therefore quiet rare to see it in actuality.
    – Sardathrion - against SE abuse
    Feb 29, 2012 at 17:08
  • 1
    You could even argue that every check-in must have a matching unit test change.
    – Carra
    Jan 12, 2018 at 15:15
  • “It's called regression testing” – It is sometimes mistakenly called “regression testing”.
    – kirelagin
    Apr 8, 2019 at 19:46
  • 1
    @heringer Personally I prefer “defect-based testing”.
    – kirelagin
    Sep 25, 2022 at 19:50

4 Answers 4

Reset to default
33

This is quite common. We use this in our team. For Every production defect, the developer must add a note on the root cause of the problem , add a failing unit test and add a test impact analysis before the ticket can be pushed to dev state to check in the code.

The failing unit test must pass before we can push the code to production.

I don't think this has a specific name except that general "regression testing". This is very useful and we have started seeing a rise in the quality of the product after we started following this process.

Improve this answer
15

Absolutely!

If you can agree that unit tests are a good thing, then you will realise that if there is a bug then there is a missing unit test covering that code path.

So what should happen is, you write a unit test that shows the bug exists, fix the actual bug, then the unit test will pass.

If you have no unit tests at all, then this can be a good way of starting to introduce unit tests to a project.

Improve this answer
0
12

The technique is test-driven development. It's not really about being able to spot a similar bug next time, although the suite of repeatable tests is always helpful. The point is that you can demonstrate that you've isolated what is wrong with the code, proved that it is wrong, fixed it, proved that the fix is correct.

There's a quote that I can't quite recall or find, but roughly it is: "Every bug is a test not yet written."

Trying to sell it as a regression test is a lost battle, IMHO. Given how infrequently these things catch a repeated bug, most developers will just say, "Why bother, when I can simply fix it?"

Improve this answer
0

This technique is pretty common and, in my opinion, the best name for it is “Defect Driven Testing” (I came up with it myself and then found it described under this name long time ago).

You sometimes might see some people call these tests “Regression Tests”, but I personally find it somewhat hard to justify this name. A somewhat more widespread definition (and one that, arguably, makes much more sense for this name) of “regression testing” is “running tests after making any change to the code to make sure that you did not introduce any regressions” and your CI that tests each branch on push to the repository satisfies it.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.