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 HATED 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 exactly 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 AND 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! :)
Top comments (1)
There is no empirical evidence that TDD improving quality (there are researches which say that there is an improvement but it is hard to say if it is due to TDD or due to other factors, like bigger time spent on development). See this talk.
TDD is not the only technique in the field, for example, there is type driven development when you write types first and then write code.
There are situations when TDD doesn't make sense, for example, when you prototype something: you want to create UI to test it's UX, and you have no idea if it is good or not, and it would take you more time to explain it with whiteboard than to write code. Following TDD, in this case, can be a total waste of time, because those prototypes rarely pass as is (at least in my experience).
There are cases when TDD is ideal - when you write a library and the problem is well understood. For example, you want to write a sort algorithm - it has been solved for a million times. You can write tests first and even more, you can write benchmarks as well.