04/04/20191 Min Read — In TDD

Yesterday I wasn't able to write a post anymore since my head was just too full of information and thoughts. The reason for this was the TDD (Test Driven Development) session I had with Wolfram in the afternoon. It was a great experience, but it also cost me a lot of brain power and energy. But first one thing after the other.

In my previous experience as a programmer, I have always written tests (if any) after the 'implementation code'. I think the reason for this is convenience, but more on that later.

As we were doing our TDD session, Wolfram explained me a lot about testing types, naming functions and much more. At one point I think I started to realize that TDD is not only a test strategy but more a design strategy. The benefit of applying TDD is not having tests for our implementation, but much more! The tests are the dominating factor, they are responsible for driving our implementation and design.

Yeah, somehow this makes sense, especially if you have a look what the first 'D' in TDD stands for: DRIVEN. I knew what this 'D' stood for before (at least I thought), but this TDD session was the trigger I needed to start realizing it's meaning.

We don't just write tests to test our code - we write them to challenge our code! We want to see them fail. We want to make them pass. We want to refactor our code as well as our tests.

I have to admit that I have found that TDD is much more difficult to apply than I thought. I also felt that TDD is not only challenging the code but also me! In my opinion, it is much more convinient to write code and then "ship one or maybe two green tests" afterward (or not). However, I don't want to go the easy way, I want to improve! I want to learn how my coding style changes when I apply TDD. Therefore there will certainly be more TDD katas on my todo list.