I can't emphasize enough the importance of writing good meaningful unit tests. This was reinforced again today when I received a request from one of our folks who said there was a bug with one of the systems for which I'm responsible. My immediate reaction was that I didn't trust the code I had written months ago. The scenario is pretty simple. If one property of a class is null, output a default value. The code is:
Writer.Write(instance.AdText ?? "Click link for more info....");
Silly me. I didn't trust the .NET Framework to work as expected so I wrote a unit test to verify that when AdText is null, the default is printed.
The bad news is I wrote the test. The good news is, it disproved my immediate invalid assumption of where to start chasing the bug down. Months ago, the process would have been to build and deploy the application then run it with an email subscriber and ads that have and don't have AdText properties. Alas, the same conclusion would have been reached but with the unit test, my silliness was pointed out to me far more quickly.
Thursday, April 29, 2010
Tuesday, March 2, 2010
Unit Testing V. The Debugger
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).
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).
Learning from our elders
Over the past 5 years, I've come to the conclusion that there is something missing in the first few years of training aspiring developers embrace when they feel the pull towards software development as a career.
Scrum and XP practices have been around for quite some time now, 10 years or more to be more precise than "quite some time now".
I believe it's time for those of us who are more or less .NETters to take a break, reflect and start looking to our SUNners across the aisle (or Oraclers). Almost every tool we use in the .NET world to assess code quality got its start with a "j" in its name or at least with the absence of an "n". This tells me that there are either more mature experienced developers who are writing or have written applications in Java from which I can learn. The alternative is that we in the Microsoft camp write flawless code and therefore do not need to lean on quality tools.
I can tell you that I personally don't write flawless code. I lean heavily on quality tools to tell me when I'm an idiot. The beauty of those tools is they typically report my idiocy only to me and not to the people who assign my bonus. Of course, when I'm a real idiot and don't ask my quality tools if I'm being one, they will also quickly report to everyone that Tim had a poor thought moment.
Many of us pour libations out to Uncle Bob and Steve McConnell while others are clueless who these guys are and why we should care about what they say.
Here's an interesting factoid. From McConnell's Code Complete 2 book, he states that "a study conducted by IBM indicated that for every hour spent doing code inspections, 33 hours of additional work was saved".
These guys have been around the block a few times. We as developers should understand that their experiences can become our experiences if we only take a moment and listen (or read).
Scrum and XP practices have been around for quite some time now, 10 years or more to be more precise than "quite some time now".
I believe it's time for those of us who are more or less .NETters to take a break, reflect and start looking to our SUNners across the aisle (or Oraclers). Almost every tool we use in the .NET world to assess code quality got its start with a "j" in its name or at least with the absence of an "n". This tells me that there are either more mature experienced developers who are writing or have written applications in Java from which I can learn. The alternative is that we in the Microsoft camp write flawless code and therefore do not need to lean on quality tools.
I can tell you that I personally don't write flawless code. I lean heavily on quality tools to tell me when I'm an idiot. The beauty of those tools is they typically report my idiocy only to me and not to the people who assign my bonus. Of course, when I'm a real idiot and don't ask my quality tools if I'm being one, they will also quickly report to everyone that Tim had a poor thought moment.
Many of us pour libations out to Uncle Bob and Steve McConnell while others are clueless who these guys are and why we should care about what they say.
Here's an interesting factoid. From McConnell's Code Complete 2 book, he states that "a study conducted by IBM indicated that for every hour spent doing code inspections, 33 hours of additional work was saved".
These guys have been around the block a few times. We as developers should understand that their experiences can become our experiences if we only take a moment and listen (or read).
Subscribe to:
Posts (Atom)