I have been practicing Test Driven Development for about a year now, and have just recently had a revelation that has led me to change my perspective. I feel that Test Driven “Development”, may better be explained as Test Driven “Design”.
In the agile world, the process of TDD is ingrained in all of us as a “must do” practice. However, many of us approach this from a completely wrong perspective. Its not just about testing, its also about design. But the terms “Design” and “Test” have historically been portrayed as polar opposites: design being done at the beginning of the project, and testing at the end. It seems counter-intuitive to combine the two into one process, but then again, the agile process as a whole is very counter-intuitive, yet very effective. So is TDD.
The project I have been working on for the last year and a half is a dynamic calculation engine that evaluates formulas defined in metadata against a datastore. It is designed to be reusable so it has to be highly extensible to meet the varying needs of multiple applications. This introduces the need for configurability. In a recent iteration, we began to see that the code to actually instantiate the CalcEngine is very unwieldy. When did we find this out? When we wrote the test! Had we written the test first, we would have quickly realized this an designed it to be simpler to use.
