TDD as if you Meant It: Some Traditional TDD – part 1 (Episode 6)
About
This is the first episode of an alternative evolutionary design approach. During the last episode (Episode 5) I refactored the code to generate a builder. The alternative presented in Episode 6 and 7 is to stop using TDD as if you Meant It for a while and start using some traditional TDD.
Traditional TDD
In a traditional TDD approach I am creating some structures up-front. I can create more or less design up-front, but still the minimum I create is the production class or function I want to test. This approach is different from TDD as if you Meant It where I am extracting the code from the test method, to the test class and to a production class.
In a traditional TDD approach we can have different approaches: bottom-up, top-down, middle-top, middle-bottom, etc. But I take this decision depending on the clear need I observe in the current moment.
Specifications with TDD
Whenever I start with traditional TDD, I need to define the clear specifications. Or in other terms, I define the clear needs of the design structure I need to add. In this current case I defined the fact that I need a fluent builder. So my current tests will reflect the need in the tests. In this approach the evolutionary part of the design is marginal. As I am very clear with what I need, I don’t need a lot of proof. This is not always the case.
Scale of Evolutionary Design
At one extreme I am in the point where I know exactly what I need. In this case any form of Evolutionary Design or TDD is useless. I might want to add automated tests (while adding the code or after) to perform the checks on the code just for regressions.
At another extreme I don’t know at all what I need, but I have the specs. So I start with them and I focus on the principles of refining the code concepts in order to extract the appropriate design entities.
During this codecast I will situate myself very close to the extreme where I know pretty well what I want. But careful to be sure you always introspect and clarify if you have all the information to take a design decision without enough proof. Your solution might be too complicated or just inappropriate.
Video
Check the video below with the codecast:
What’s Next?
Check the next episode on TDD as if you Meant it here: http://blog.adrianbolboaca.ro/evolutionary-design
On the same page you can find more ideas on Evolutionary Design.
Credits
Many thanks to Keith Braithwaite for creating the concept of TDD as if you Meant It
Teddy bear thanks to Erik Talboom for all the pairing, discussions that lead to so many twists we discovered together with TDD as if you Meant It.
Special regards to JB Rainsberger for the fun pairing we did using TDD as if you Meant It