How I Test and Debug Code
on Fri Jan 06 2017
My thought process in testing and debugging...
I try to keep a certain thought process when it comes time to test and debug my code. Here's a quick overview of the basic process in which I mentally adhere to:
- Understand the problem.
- Understanding the problem allows us to come up with a concrete solution. If we don't understand the problem, we tend to have difficulties implementing our solutions as we end up coding for corner cases in which we fully don't understand once the bug reports come in. Awkward.
- Understand the extent of the use of the particular piece of code. Know the purpose and use cases.
- Know what your routine is expected to output. This is very important — how would you know if a case should generate correct output when you are not sure about the output in itself? This goes back to the first point in understanding the problem.
- Test a few happy cases. First, start off with very simple cases, then move onto nice, complex cases in which you are sure your code can handle.
- Not only does this check for the sanity of your implementation, but I find it to be a good confidence booster.
- Test the bounds up front. Test any cases that may stress the routine.
- Remember all the easy cases in which you have tried. They will become the "smoke tests".
- List any complicated cases, or cases you may think can break the code. A hunch is better than nothing!
- Think about invalid data types and bad user input — how would the routine fail? How would it react?
- What happens when there is no input?
- Once confident and points 1-9 are concretely understood and defined, I can usually call it a day. 🙂