CodeBetter.Com
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @CodeBetter

Rod Paddock


My First TDD Dividend(s)

It’s now 6:30am here in Austin, TX and my first forays into TDD have paid their first real dividends.

Roy Osherove (http://weblogs.asp.net/rosherove/) and I spent a couple of hours yesterday going over my system framework/architecture, installing nUnit and Test Driven.NET. We wrote one very simple contrived test and then left for BBQ with our bud Scott Bellware.

So it’s 4:00 am and I cannot sleep so I get up, do some client work and then return to so some tests on my own.  So I refactored my customer business object. I added a rule to check that the last name is filled in.  Then I wrote another test. The goal of this test was to make sure my validation engine worked and returned the proper error conditions.

So I ran the test and it failed. I’m like what? This should have worked. Why didn’t my rule(s) fire? So I looked into the framework code and low and behold. Looks like I never finished wiring in our new validation rules engine. 

BINGO: Dividend 1 paid. We now need to finish wiring in the new validation engine.

So now I returned to making the test pass. I had a hook point where I could wire in manual calls to the validation engine. So I did that and restarted the test.  Boom another failure. Now what happened? We have a set of code the integrity of the data being returned. Well when we have a data validation error we don’t return that data.  Nice thing is that this section of the application is created via code-gen. I simply changed the script to test for the error condition. Now our test passed.

BINGO: Dividend 2 paid. We needed to fix some of our codegen templates.

So with just a few simple tests I found two very significant bugs in our framework. It’s nice to see that this stuff pays off so quickly.

The nice thing is that now I am confident that this stuff pays great dividends (and very quickly I might add). Also it’s great to see that it CAN be implemented against our framework.  

 

crossposted from blog.dashpoint.com


Comments

cmyers said:

Once you get test infected, then the other things, like DI/IoC for example, start making more sense. Admittedly, they're not super useful unless you're religious about testing which is why I think a lot of people don't understand/get irritated by the TDD/Agile/ALT.NET crowd because all these things seem like extra work.

It all starts with TDD, really, and then you start writing code differently in order to make them easier to test.

IMHO, code written to be tested is also code written to be used. It tends to be more open and extensible and easier to change/override/extend.

Some of the best framework/API-type code I've ever written was code that was developed using TDD.  It pays off in more than just bug prevention, it pays off in the resultant good, quality design.

Not to mention that TDD code is code that has actually been used by at least one person!  Before TDD, much of the code I wrote was YAGNI stuff that didn't get hit for months or years and then suddenly a bunch of bugs were found!

# October 5, 2007 12:32 PM

Jay Kimble said:

Not to be nit-picky here (but as a guy who has/is doing what you are describing Rod)... it sounds like you are testing a system that you think is done?  

That's writing unit tests not necessarily doing TDD.  Not that I will say much more than that.  I have found writing unit tests with the TDD tools extremely useful... doing pure TDD not so much (but that's me in a very limited fashion)

I have written about this type of thing and have gotten blasted for not truly being TDD.  For me the ability to whip out the debugger long before the actual interface is written (be it a web site, a windows form, console app, serivce, etc.) is extremely useful.

# October 10, 2007 7:40 AM

Leave a Comment

(required)  
(optional)
(required)  

Enter the numbers above:
Add
Check out Devlicio.us!