TDD as if you Meant It: Experiment Design Alternatives when Stuck (Episode 9)
About
During this episode you will see how I formulate experiments to decide where it is a good idea to get the design.
Refactoring
Evolutionary Design happens during refactoring. This episode is just refactoring, but with a clear purpose. The purpose is to identify, with a clear hypothesis, if a certain design solution would be suitable. The word suitable is very unclear, so when formulating the experiment I want to make my expectations very explicit.
There are many reasons to do refactoring. During this episode you will see a refactoring that is focused on discovering (one of) the correct ways to create the design entities.
Experiments
When I formulate my experiments I take the following steps:
- Define the hypothesis
- What would be good if this experiment succeeds
- What would be bad if this experiment succeeds
Experiment example
- Hypothesis: “two by two”, “one by one” should be a class “BoardStructure”
- Plus
No more primitives about BoardStructure in the tests
All the structure will be in one place. Structural coherence.
Some coupling is expected from the tests, but only one other class will use boardStructure
Duplication will be removed in-between tests
Clarity will be better because a cohesive design structure is extracted - Minus
Increased code complexity, because of a new design element
After the experiment
If the experiment succeeds, I can take the decision to keep the changes, but only if I am sure I don’t need more proof. And it’s not about lying to myself that the solution is ok. I really need to be honest to myself and if there’s the least doubt, I need to go back, revert the changes and try again by adding more tests.
If the experiment fails, I note down the situation and the solution. Either in my head, or I document it somewhere. It is important not to try it again in that context, because it would be waste.
I learn a lot more from failed experiments. I understand which are the solutions I should never chose and the solutions that work only in certain situations. If you don’t have at least a few failing experiments it means you are lying to yourself that you found the correct solution from the beginning.
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
Really enjoying following this series, so glad I found it after attending one of you live coding sessions last year!
Just curious; I appreciate your removal of statics to avoid hidden dependencies but is this the same reason you wouldn’t convert your Direction class into a Java Enum?
I believe I don’t have enough proof that the Enum is a good solution for the class. An enum has more coupling and doesn’t respect the Open Closed Principle. So I would triangulate more on this direction until some elements are clear:
– is direction really a good concept. Should it be here?
– how much would direction need to change?
– do I need to inject direction as a dependency or can it be inside the core code?
– how much coupling is normal to have between direction and the rest of the code?