When using TDD as if you Meant It we need to have a clear distinction between the test code, and the production code written in the test methods and classes. The more we dissociate the two, the clearer both production code and test code look. During this episode I made the final steps to separate production from test code. This is a final step of the triangulation of a specific concept.<\/p>\n
When I started triangulating on the concept of Game, I made an analysis on inputs and outputs (called Behavior Slicing and explained in Episode 1<\/a>), that lead me to write enough tests to be able to understand it. By triangulation in this case I mean adding enough tests to understand the links between the design entities. In some cases I need more tests, in others just a few. And of course the number of needed tests depends also on the experience of the coder.<\/p>\n When separating the two, we need to make sure everything is clear from any point of view: class names, package names, code structure in the IDE, etc. The code at the end of the separation needs to look as if we wrote it in a separate way all along. Whether we apply traditional TDD (where we write the test code in a separate file from the production code from the beginning), or we apply TDD as if you Meant It, the code structure needs to look the same. Of course, the design will be very different in many occasions because with TDD as if you Meant It we can zoom more on the simplest design possible.<\/p>\n After this whole process of Behavior slicing<\/a> to refactoring (Episode 3<\/a>, Episode 4<\/a>, Episode 5<\/a>), to clean-up<\/a> and to extracting production code I need to identify the next design concept to triangulate to. So stay tuned to see the whole TDD as if you Meant It process all over again, but with another concept related to the Game.<\/p>\n Check the video below with the codecast:<\/p>\nSeparation<\/strong><\/h2>\n
Next step?<\/h2>\n
Video<\/h2>\n