Today I checked in a change on some code which turned out to be not working at all due to something rather stupid yet very crucial. I feel really bad about it and I hope I finally learn something from it. The stupid thing is, I've done these things before and I always tell myself, next time I won't be so stupid... Then it happens again and I feel even worse about it.

I know you should keep your chin up and learn from your mistakes but here's the thing: I try to improve myself, I just don't see how I can prevent these things from happening.

So, now I'm asking you guys: Do you have certain groundrules when testing your code?

closed as primarily opinion-based by durron597, user40980, GlenH7, user22815, Dan Pichelman Jul 17 '15 at 21:02

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.


Write tests before you make code changes.

If your proposed change is to fix a bug, have the test fail at first by demonstrating the bug. Then make sure it passes after you have fixed the bug. If you write the test afterwards and have only ever seen it pass you can't be sure it properly tested the bug in the first place.

If your proposed change is to change existing functionality or add a feature, write some tests to ensure good coverage of the area of code you will be changing. Make sure these tests pass before you start changing code, and still pass when you finish.

  • This is really good advice, it may take a bit longer to get a bugfix out but it damn sure won't cause me to make this sort of mistakes again and it will allow me to write more stable code overall. – Peter Feb 16 '11 at 12:01
  • @Peter it should save maintenance time in the long run. You should need to spend less time manually smoke testing fixes and also the tests will be in place for the next time the code is edited. Sometimes you may even find that quickly writing a unit test that reproduces the bug can make it faster to debug and fix the bug in the first place. – Alb Feb 16 '11 at 12:06
  • @Peter I often find myself reproducing the bug several times while fixing it. Writing a small test instead usually saves time, not to mention that you can be absolutely sure it works (and will work in the future). – DasIch Feb 16 '11 at 17:59
  • this is such a fantastic advice buddy, thank you so much ! – Shaheer Sep 19 '11 at 4:06
  • @Alb or even in the short run. – user1249 Mar 23 '12 at 8:40

Don't forget to test edge cases! Lots of bugs are because the most common action was tested but not the less common ones.

  • Imho the real gem is in finding these edge cases. I am often surprised with the bugs that come out of a system, just because we didn't think of a particular scenario. – Peter Feb 17 '11 at 7:06

Follow the technical advice in the technically-oriented answers; it's good stuff. My answer is more about attitude.

Feeling bad about making the kind of mistake every developer makes occasionally is just absurd, and doesn't help you not make that kind of mistake in the future. While you sit there feeling bad, the build is still broken, you know? And then your work is all about avoiding mistakes, which I know makes getting out of bed in the morning an exciting adventure every day, right?

I've heard of companies where checking in broken code is cause for public shaming. I can't even get my head around the kind of warped, frat-boy, junior-high-level thinking that would lead to such behavior. There could hardly be ANYTHING more counter-productive for a team lead or manager to do.

So don't beat yourself up. We've all done it. I probably cost myself half a day per week in silly mistakes, and I've been doing this for (cough) a long time. That's what it looks like to write code--you're constantly bashing up against what seems like your own inadequacies. What makes a professional a professional isn't some mythical quality of never ever making mistakes (including big ones sometimes), but how they RESPOND to the mistakes they make.

If there's one mantra I could instill in every developer I work with, it's this: You are not your code. You write code. You write it as well and efficiently as you can. Then you go home. If you equate your value or self-worth as a person with the quality of your code, you're just missing the boat about who you really are.

  • I understand what you say about public shaming, but at the same time it's frustrating to be blocked because the build is broken because Joe Bloggs didn't build all platforms before checking in. – tenpn Feb 16 '11 at 15:08
  • @tenpn - Totally. But the flipside of what I'm saying is also true about Joe Bloggs. He's also not his code. As colleagues, we have to resist the impulse to turn Joe into an idiot in our eyes because he made a mistake that any of us could have made. – Dan Ray Feb 16 '11 at 15:23
  • @tenpn actually, you could also blame the system for not automatically testing the build before commiting the changes to the trunk/master. – David Feb 16 '11 at 16:48
  • 2
    @tenpn - Neither is beating on your co-workers. – Dan Ray Feb 16 '11 at 17:38
  • 1
    What if the change doesn't break the build? It's common sense to build your code before checking in. It's not so obvious to test your code in every possible way. There's always some scenario you couldn't have though of. Just today I ran into a floating point rounding error which happens only if you happen to have the right(wrong) numbers – Peter Feb 17 '11 at 15:24

Another important testing practice is to write the test and make sure that it fails at least once BEFORE writing the code. It's all to easy to mess up and write a tautology test that accidentally doesn't test the condition you are checking for. False assurances are almost (and sometimes worse) than no assurances.


One Idea I have used from time to time is this,

create a branch and break your code, run the test and make sure that the test catches the error.


Do you have certain groundrules when testing your code?

  • Always unit test your code, and try to reach as high coverage as possible.

Some additional general points :

  • invest some time into design and planing before starting to code
  • refactor your code!

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