I had a skype call today with Rob Conery and Scott Bellware (twitter) today to talk mainly about how to improve the “TDD message” of his latest ASP.NET screencasts.
One of the points of feedback Rob got on his screencast is that he had stubbed the code he wanted to test before actually writing the test. While there was no “meat” of the code he wrote, there was still code. And that code had some sort of design baked in already.
The topic in question was about Products. Rob had a fictitious requirement that the discount should be displayed next to the price. So he created something like this as a stub:
public class Product
{
public float DiscountPercent { get; set; }
public decimal ListPrice { get; set; }
public decimal AdjustedPrice
{
get { return 0.0m; }
}
public decimal DiscountAmount
{
get { return 0.0m; }
}
}
The intent was to test that a discount was properly applied to the product. Of course, the test fails initially, and then you can easily go make it pass, but the first activity performed was stubbing out code, and that is design.
Instead, a failing test should show with absolute opactity that there is even a need for those properties. The fact that you’ve written a test specification that says:
A Product with a discount percent of 10 and a list price of $100 should yield a discount amount of $10.
This becomes executable, and you know immediately that you have to implement those properties.
“But wait?” I can hear you say, “…didn’t you just come to the same end result?” Well, yes, here I did. But what if while writing this code you realized that you really need to calculate this amount when you are calculating an order total, then you might introduce an order object. Or you might have a completely different need. The point here is that you shouldn’t just assume that you’ll need those 4 properties, or this 1 method, because you’ll likely be wrong.
This also brings out the point of having good test naming. The test name should be so descriptive, it’s like a rule for the application. Any new developer can come onto a project and decipher the meaning & intent of broken tests. That is a very valuable thing to have.
If you recall the original fictitious requirement, it was “the discount should be displayed next to the price” you can see that it is a UI requirement. It doesn’t necessarily dictate the model that you must use.
In fact, you might even come to the conclusion to use a data transfer object as a presentation model and then this piece of information could literally come from anywhere.
TDD is about design. You’ve heard that a million times. The obvious corollary benefit is the enforced existence of automated tests for every possible specification. Even if you intend to write the tests immediately afterwards, you may have missed out on some critical aspects of design, such as loose coupling, or eliminating waste. You’re also tempted to just not write tests at all.
If you skip on the test-first nature of TDD, then you’re really just unit testing, and you’re missing out on the real design benefits of TDD.
I also want to point out that I’m not picking on Rob. He’s had way too much of that. I think he’s doing a great job and (if done correctly) he can definitely reach a larger audience than I can, seeing that he works for Microsoft. I also think it takes guts to submit your work to the world and, in the face of some pretty harsh criticisms, stand up and say… “Hey, why don’t you get on skype and we can talk about how much I suck!” — Keep it up, Rob!
So here’s a challenge: those of you who think that Rob did a “disservice” to the community, I’d like to see your screencast on the subject. Obviously there is a gaping void instead of widespread adoption, so we as a community could definitely use the material.