This is the first episode of an alternative evolutionary design approach. During the last episode (Episode 5)<\/a> 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.<\/p>\n 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. 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<\/a> builder<\/a>. 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.<\/p>\n At one extreme<\/strong> 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<\/a>. 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.<\/p>\n <\/p>\n <\/p>\n Check the video below with the codecast:<\/p>\nTraditional TDD<\/h2>\n
\nIn 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.<\/p>\nSpecifications with TDD<\/h2>\n
Scale of Evolutionary Design<\/h2>\n
\nAt another extreme<\/strong> 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.<\/p>\nVideo<\/h2>\n