3 ms·
The top reason is indeed Knowing Your Code Works. Be it because requirements keep changing, new features are added, many people working on the same code, refac
by tellarin 14y ago
The top reason is indeed Knowing Your Code Works.
Be it because requirements keep changing, new features are added, many people working on the same code, refactoring, whatever... Having good unit and functional tests catch a huge amount of problems that would be hard to find latter.
The other two points are pretty minor in my view.
And the suggestion to improve code coverage is just cheating. There's no excuse for that. Either don't track stupid metrics, don't add unnecessary catches, or properly test exception code.
EDIT: Clarified text.
- gav 14y agoNot just knowing your code works, being able to capture what the code is supposed to do for the next person that comes along. For example, this week I've been working on refactoring some code that had some performance problems. Digging into the code I found a lot of confusing logic and had to waste a lot of time stepping through the code trying to understand what it was doing. If there were unit tests, I could have treated it as a replaceable black box.
- laceysnr 14y agoThe coverage cheat is for the platform. I don't control the metrics so sometimes working around them is necessary. I would never fudge something to meet a personal standard, my standards are against nonsensical metrics.
- randomdata 14y agoTop reason is documentation. So future readers can read about your intent and understand how the code functions. "Knowing your code works" is just validation that your documentation is true to what the code says, which is one reason why we prefer testing to comments.