Thursday, August 13, 2009

Design For Test

It sounds straightforward. Write your test code first, then write code to pass that test. Don't write an inch of code without writing a test first. That is what test-driven development (TDD) is about: Use tests to drive out the design and implementation. Rinse and repeat. Repeat many times a day.

I know a number of top notch developers who are masters at their craft. Yet they don't daily program in a pedal-to-the-metal test-first-only write-the-barest-amount-of-code-to pass the test style. Yet they value testing. Testing, to them, is integral to programming. I asked a few of my programmer buddies who value testing what does it mean to design for test (I have my ideas, but I don't make my daily living writing production code)...even if they aren't TDD followers.

And the bottom line is this: code that is designed for test must continually be tested (not necessarily at the speed of a TDDer). If you want to make testing feasible, you often need to make code-under-test easy to isolate from its production environment, tunable, and measurable. Not easy stuff. Just like design flexibility, testing doesn't come for free. It's part of a disciplined development process.

Read more about Design For Test in my latest IEEE Design Column.

I'd like to hear your reactions...

2 Comments:

Blogger John said...

That's a good article about Design for Test. Another thing that I like about TDD is that it has this "side affect" of creating API documentation. As a programmer I always like to see how an API is used in some context rather than just see a document that says, "here is API x that does y". At least with the test cases you can see how the API is used. Through some clever Doxygenation, one or more of the test cases can even be a part of the documentation for a class.

7:18 AM  
Blogger Rebecca Wirfs-Brock said...

Yep... interfaces are best understood when demonstrated. So I like to see how they are used, too. But a lot of tests can be difficult to wade through. So somehow, I'd like to see a good way of separating out what not to do (when using an interface) tests, from what to do tests. And labeling them somehow.

12:10 PM  

Post a Comment

<< Home