TDD as if you Meant It: Experiment Design Alternatives when Stuck (Episode 9)

The book Facilitating Technical Events is for technical trainers, coaches, events organizers who want to have a good event flow and happy attendees.
Support independent publishing: Buy this e-book on Lulu.

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:

  1. Define the hypothesis
  2. What would be good if this experiment succeeds
  3. What would be bad if this experiment succeeds

Experiment example

  1. Hypothesis: “two by two”, “one by one” should be a class “BoardStructure”
  2. 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
  3. 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

 

Subscribe

If you want to receive an email when I write a new article, subscribe here:

Subscribe for new articles

2 thoughts on “TDD as if you Meant It: Experiment Design Alternatives when Stuck (Episode 9)

  1. 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?

    1. 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?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Subscribe for new articles