Don’t even think about releasing a piece of code, if you haven’t stepped through every line at least 50 times with a debugger.
What? Are you serious? But I have written so many unit tests!
It is true, unit tests are an important aspect of long-term code quality, but they are just not enough. When you write a unit test, it is too easy to become optimistic and be absolutely sure that certain parts of your code work. It is easy to forget the internal workings of your code, and skip some edge cases, and unless you write and execute school like test suits, it is too easy to leave things out.
Is there a correct way to do it?
When you step through your code, stop before every line you execute, and try to think what you expect it to do. Execute the line and compare your result with the expected result. Work in several abstraction levels. Debug every line of the method you’ve written. When you think it is working fine, treat it as a black box and debug the methods that call it without stepping into it. Sometimes code that seem correct in one abstraction level, will turn out to be faulty when you examine it from another.
Hila, you are so smart! I’ve found a bug!
Why, thank you! *brushes off an imaginary hair from face and beams graciously*
Now turn it into a unit test. Why? Because the next thing you will fix will probably break your code again. Run your test, make sure it fails. Fix the bug, make sure the unit test passes.
Ok, my code looks like it is working now. Can I stop debugging?
Nope. Go ahead, run it again. You will find another bug.
Arrgh! This is so much work!
Too bad, writing quality code is what you are paid to do. If you don’t like it, I heard Walmart are recruiting now.
Isn’t it better to spend the time implementing cool new features and having my QA test the code?
No, from several reasons. They cannot do it as well as you can. Not because they are stupid, but because they don’t know your code as well as you do. In fact, even the future you cannot do it as well as you can. If you move to another task and postpone cleaning up after yourself until you get your inputs back from QA, you will definitely not remember all the little details of your implementation, and these bugs will be a lot harder and a lot more costly to solve. And finally – it is not the QA’s job to find these bugs, they have more important things to do, like making sure the whole system is functioning from the user’s perspective and testing the overall design and integration points. If they have to deal with the bugs you were too lazy to fix all day long, when will they have time to do the real work?
Trust me, step through your code (and wear sunscreen). Your QAs will thank you. Your future you will thank you. Your manager will thank you. Your users will thank you. I will personally thank you. Your neighbor’s cat will…
Hila, can I ask you something?
Yes, yes, I am implementing a new subsystem now and I’m finding trillions of funky bugs by stepping through my code.
Now go away! I’ve just hit a breakpoint!