3 ms·

Red/Green is a good technique for fixing bugs and extending existing functionality.

koonsolo 5y ago
What is the chance of a fixed bug getting broken again? As it turned out in our analytics over 10 years: very very low. So the effort you put into writing a test for a bug, has most likely a negative return on investment. That time could be better spend somewhere else.
- RHSeeger 5y ago
  You're ignoring various parts of the equation, though. - Writing a test for a bug is part of understanding the bug, much like rubber ducking, it helps you make sure you know exactly what causes the bug. - The better you are at writing tests, the less time it takes you to do so. - Having tests for the code means the code is testable. In general (but not always), code being testable means it's better code (more readable, less complex, etc). - Having tests for code means you have to worry less about breaking it when making changes. This allows work to proceed faster. So it's not just "did adding this test prevent this one bug from re-occurring", it's "did adding tests improve our development overall". The later is far more likely to be true than the former.
- duncan-donuts 5y ago
  Maybe for you and your org though. This isn’t universal. I’ve worked somewhere that would use the phrase “whack-a-mole bugs” because teams would start thrashing and break each others’ shit over and over. There’s a ton of stuff we could have done — communicate (even just a tiny bit), less silos, communicate!, write better code, write tests. When your problems are much more fundamental, like teams just flat out don’t talk, writing the test is an easier investment.
- synthc 5y ago
  I disagree: when fixing a bug I usually start with writing a failing test that reproduces and exposes the problem, and then fix the problem so that the test passes. Understanding, reproducing and fixing the problem is the hard part, once that is done making a test out it hardly takes any time. Writing the test does not only prevent regressions, it also helps with confirming you actually fixed the bug.

What is the chance of a fixed bug getting broken again? As it turned out in our analytics over 10 years: very very low. So the effort you put into writing a test for a bug, has most likely a negative return on investment. That time could be better spend somewhere else.

RHSeeger 5y ago
You're ignoring various parts of the equation, though. - Writing a test for a bug is part of understanding the bug, much like rubber ducking, it helps you make sure you know exactly what causes the bug. - The better you are at writing tests, the less time it takes you to do so. - Having tests for the code means the code is testable. In general (but not always), code being testable means it's better code (more readable, less complex, etc). - Having tests for code means you have to worry less about breaking it when making changes. This allows work to proceed faster. So it's not just "did adding this test prevent this one bug from re-occurring", it's "did adding tests improve our development overall". The later is far more likely to be true than the former.
duncan-donuts 5y ago
Maybe for you and your org though. This isn’t universal. I’ve worked somewhere that would use the phrase “whack-a-mole bugs” because teams would start thrashing and break each others’ shit over and over. There’s a ton of stuff we could have done — communicate (even just a tiny bit), less silos, communicate!, write better code, write tests. When your problems are much more fundamental, like teams just flat out don’t talk, writing the test is an easier investment.
synthc 5y ago
I disagree: when fixing a bug I usually start with writing a failing test that reproduces and exposes the problem, and then fix the problem so that the test passes. Understanding, reproducing and fixing the problem is the hard part, once that is done making a test out it hardly takes any time. Writing the test does not only prevent regressions, it also helps with confirming you actually fixed the bug.