33

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.

  • 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 '12 at 16:32
  • 23
    It is best practice to do this and therefore quiet rare to see it in actuality. – Sardathrion Feb 29 '12 at 17:08
  • 1
    You could even argue that every check-in must have a matching unit test change. – Carra Jan 12 '18 at 15:15
  • “It's called regression testing” – It is sometimes mistakenly called “regression testing”. – kirelagin Apr 8 at 19:46
26

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.

14

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.

11

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?"

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.

protected by gnat Apr 8 at 20:53

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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