Home » 2014 » March

TDD Isn’t All About Testing

tran-land-045While the artifact of Test Driven Development is test code, what you get out of test driven development far exceeds the test themselves. 

Maintainable Code

By writing test first, you tend to write code that is more highly maintainable than if you just wrote the code to solve the problem.  By writing a class so that it can be used in both the system you are writing it for and so that it can be tested, you’ve been forced to think about the code in at least one other way from what you would have initially.  The result is your code tends to be more structured than it would have been otherwise.

Continue reading “TDD Isn’t All About Testing”

When You Really Need All Of Your NUnit Test In One Class

Last week I proposed a structure for unit test that follows the pre-condition, action, post-condition workflow.  Basically what you would see in a Use Case document.

The result of this structure when applied to a general NUnit class is that we will end up with our pre-condition and action in our setup method and our post-condition asserts in our test methods.

The problem with this is that sometimes this doesn’t always fit what we are trying to do.

Continue reading “When You Really Need All Of Your NUnit Test In One Class”

Unit Test Structure

UnitTestingScreenOne of the recurring reasons I hear from people for why they are not implementing unit test in their code is because it takes too long.  On one level I get that.  But, my experience tells me that the real problem is more likely that they just don’t understand enough about how to implement unit testing to be able to do it well.

This is like knowing you are supposed to “eat right” and “exercise” but not having anyone tell you how to do either in such a way that you can maintain the habit.

Continue reading “Unit Test Structure”



A long long time ago, in what seems now like another world, I worked for a company as a Clipper programmer.  While I was there I heard this story about a lady named Debbie.

I was told that Debbie was a programmer who used to work for this company.  Debbie was a lazy programmer.  She worked harder at avoiding work than if she just did the job she was supposed to do.

The ultimate lazy programmer

For example.  Once my boss had stopped by her desk to see how she was progressing on a report she was supposed to be writing:

Continue reading ““Debbie-Done””