Test-Driven Development

For this week’s blog, I decided to find a blog that discusses test-driven development (TDD). I found a blog called “Test Driven Development is the best thing that has happened to software design” by Arek Torczuk. In this blog, the author walks through how they apply key elements through real examples. Throughout the blog, they explain their reasons for implementing TDD and walk through how to use TDD on code that is impossible to test. They split their explanation of how to test impossible code into small sections that include bits of example code to aid in the explanation. I found the organization of the blog along with the various examples to be particularly helpful in aiding the reader understand the topic and stay engaged.

The author first explains that TDD is implemented in a fail, pass, refactor cycle approach. They shorten the idea by explaining that “our focus remains on the ‘what’, and our knowledge of ‘how’ is postponed.” In this section, the author also provides a visual which I find to be effective in blatantly pointing out the important details of this section. They then go on to explain the differences between when tests are driven by code and when code is driven by tests. When tests are driven by code although the tests written for the code may pass it may not be the right approach as feedback about implementation and design may be lacking. There are 2 questions that one has to ask themselves when they take this approach: “When should I stop adding new tests?” And “Am I sure the implementation is finished?”. The latter approach (when code is driven by tests) forces you to ask yourself “What do I expect from the code?”. When code is driven by tests, you know when to stop. TDD provides fast feedback.

The various examples of code that are impossible to test were interesting to read through. One example I found fascinating was the “Bloated setup” and the “Mocking Hell” scenarios. The first scenario is where an object either has too many dependencies or the Single Responsibility principle has been broken. The author explained that in this case you should you should rethink your design. The latter is where a mock returns a mock that returns a mock.

Overall, I think this was an interesting read. I think reading through the various examples of how to test impossible code will be useful for the future as I will have to think through how to test different kinds of code and when I should rethink certain designs.