How I test and debug code.
January 6, 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.
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.
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.
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. :)
- Not only does this check for the sanity of your implementation, but I find it to be a good confidence booster.