Is TDD the Savior?
Tags: tdd, productivity, codequality, discuss
Published: 2019-08-30 21:25:08

First of all I want you to discuss with me about my arguments after you have read my post, as this is just a snippet from my todays thoughts.

At nearly every conference I ever went, there was at least one lecture about TDD, how the "big companies" deal with it and that it is like the Garden Eden when you get all your developers to the point, that they really live TDD. As I heard all these lectures in my junior developer years, I was amazed by those people. I thought it has to be fantastic to work in a team that lives and loves the process of writing tests before the actual code, because the code can't have any errors then.

So, when I came back from the first lecture about the importance of TDD my motivation for writing tests increased about 1000%. But when I sat down on my first project in the company it was so damn hard for me to write unit tests. Although I now knew the theory about how to do it... it was something completely different to write them in practice. I tried and tried and it took me so damn long to write only few tests for very simple functions. And for every test I wrote that failed I asked myself: "is it the test that is false or doesn't my function do what I've expected". So every test was married with frustration and aimlessness.

From then on, I <strong>HATED</strong> writing tests. Furthermore, I wasn't amazed about the topic TDD anymore. 

As I became better and better in different languages and my programming skills itself got better, it didn't seem to be hard anymore to write some tests for my functions and classes. The syntax and semantics seemed quite comfortable now. I couldn't test the most complex functions alone, but that was ok, as I had my senior developers there, that I could ask.

Although I am the youngest member of the team now, it seems like I am the most experienced one with the new languages used in the new project. It feels like my daily task for every pull request or pair programming session is that I ask "Have you already written your unit tests?". Furthermore, as I refactored a lot of code lately, I wrote so much tests, that i really got goose bumps when I saw the result. I was so proud of myself that I am now so comfortable with writing tests to prevent our application from getting bugs cause of changed code. And of course I am proud of the journey I have experienced.

And <em>exactly</em> this turn in the story brings me to my opinion about TDD in projects. I think that it doesn't make sense to tell a team with junior developers, senior developers and something in between, that TDD is the way to go. The junior developers will often be frustrated, because they can't always ask the seniors for help. The seniors are frustrated because they can't do the work they usually could do. 

So maybe the best way to go in such a mixed team is to write the tests after the coding <strong>AND</strong> the code review. Because that is the time that usually your code should do what you expect. On top of that, you can then prevent bugs in the code, because your team can always check if the code still works with a lot of tests.

In my opinion, everyone will experience the same journey as I did with writing tests. The point is, how hard will it be for them?

Let me know what you think about this or if you have made similar experiences in your career! :)