|
|
|
|
|
|
by Brotkrumen
2898 days ago
|
|
|
His claim of lacking empirical evidence shows his lack of research on the subject. There's tons of research that consistently shows comprehensive testing during development makes your product better and cheaper over its lifetime. Just a quick google and not even the paper I was thinking of: https://softwareengineering.stackexchange.com/questions/6050... |
|
|
The rule of thumb I always come back to is "the minute you decide it's time to attach a debugger, be prepared to burn an hour." I used to not mind firing up the debugger -- heck, I used to run my code with a debugger attached every time I ran it. These days, I write tests. I don't aim for 100% code coverage, though I aim for a majority and 100% coverage of critical paths. When I encounter a problem that isn't covered by a test (rare), I write a test centered around the problem. This usually surfaces the bug before I've even ran the actual test -- and once that test is there, any refactoring that affects that code will avoid that bug if the test passes.
This rule has been so effective for me that I've now gone through four different teams, encouraging each to do "the next project" with automated testing. The result has been a commitment to working that way from that point forward[1].
[0] Assuming some baseline quality requirements -- automated build, and a general requirement to publish a mostly functional product. :)
[1] I can't take full credit for the idea -- it was a blog post that convinced me to try it on myself and I advocated that idea after it convinced me.