{"id":2067,"date":"2017-10-16T16:11:34","date_gmt":"2017-10-16T13:11:34","guid":{"rendered":"http:\/\/blog.adrianbolboaca.ro\/?p=2067"},"modified":"2020-01-15T22:59:09","modified_gmt":"2020-01-15T20:59:09","slug":"tdd-meant-experiment-design-alternatives-stuck-episode-9","status":"publish","type":"post","link":"https:\/\/blog.adrianbolboaca.ro\/2017\/10\/tdd-meant-experiment-design-alternatives-stuck-episode-9\/","title":{"rendered":"TDD as if you Meant It: Experiment Design Alternatives when Stuck (Episode 9)"},"content":{"rendered":"

TDD as if you Meant It: Experiment Design Alternatives when Stuck (Episode 9)<\/h1>\n

About<\/h2>\n

During this episode you will see how I formulate experiments to decide where it is a good idea to get the design.<\/p>\n

 <\/p>\n

Refactoring<\/h2>\n

Evolutionary Design<\/strong> 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.<\/p>\n

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.<\/p>\n

Experiments<\/h2>\n

When I formulate my experiments I take the following steps:<\/p>\n

    \n
  1. Define the hypothesis<\/li>\n
  2. What would be good<\/strong> if this experiment succeeds<\/li>\n
  3. What would be bad if this experiment succeeds<\/li>\n<\/ol>\n

    Experiment example<\/h2>\n
      \n
    1. Hypothesis: “two by two”, “one by one” should be a class “BoardStructure”<\/li>\n
    2. Plus
      \nNo more primitives about BoardStructure in the tests
      \nAll the structure will be in one place. Structural coherence.
      \nSome coupling is expected from the tests, but only one other class will use boardStructure
      \nDuplication will be removed in-between tests
      \nClarity will be better because a cohesive design structure is extracted<\/li>\n
    3. Minus
      \nIncreased code complexity, because of a new design element<\/li>\n<\/ol>\n

      After the experiment<\/h2>\n

      If the experiment succeeds, I can take the decision to keep the changes, but only if I am sure<\/strong> 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.<\/p>\n

      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.<\/p>\n

      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.<\/strong><\/p>\n

      Video<\/h2>\n

      Check the video below with the codecast:<\/p>\n