From a recent presentation I delivered, it finally hit me that the craft of debugging is really a form of manual unit testing. Yes, this may be a "duh!", but this was an "ah hah!" moment for me.
Think about it.
You compile your application and start it in the debugger. You then click, select, submit, type and probably click your way to the part of the code you want to make visual assertions on. You'll use watch windows and breakpoints so you can inspect the outcome. You then repeat this until the code is doing what you expect.
This is synonymous with:
1) instantiate the test subject (probably a class).
2) establish its initial state.
3) call a method on it.
4) use Assert()ions to determine if the outcome is the expected one.
5) repeat
Interestingly enough, it takes FAR longer to compile (integrate), run the debugger (instantiate and set up initial state), then make the Assert()ions (watch window, breakpoints and immediate window) then repeat the process. Also, you are human and therefore are subject to all sorts of distractions that minimize the probability of executing the same code path every time. This results in poor testing and invariably less than satisfactory code quality. Add 5 scenarios you need to test for the chance of screwing up is greatly exacerbated.
Unit tests, on the other hand, are repeatable, not subject to human distraction, do not require full integration of the application and can be shared with your team.
You'll find, if you're new to Scrum, that unit testing will save you a ton of time and give you a much better chance of burning down to zero instead of burning out.
If you're interested, let me know and I'll be happy to share my recent Unit Testing 101 slide deck with you as well as sample code (.NET) that demonstrates the basics as well as advanced concepts using a great addition to the Mocking world known as "Moq" (Mock You).
No comments:
Post a Comment