TDD: What Was It Designed For?
Posterior to my writing about clean test that can be found here, the time now has come for me to talk a bit about TDD. Test-Driven Development was originally developed by Kent Back in the late 1990s as part of the well-known software development method, Extreme Programming. Was developed about twenty years ago, but the powerful concept is still relevant at least until this article is being written.
So what is TDD about? A must-do method for our projects? One thing that will ensure our code is working as expected? Annoying thing that will ban the existence of the Quality Assurance team from the world?
Test-Driven Development is a way of managing fear during programming
— Kent Beck
That was written as the opening of Test-Driven Development By Example book written by Kent Beck. With that being said, the core concept Mr. Beck trying to introduce to us is the ability to manage our anxiety when developing software. The aim is to discourage us from being too careful or afraid to take even the smallest step to cross the river since TDD is there as your stepping stone.
The Guide, The Mantra
There are mainly 2 things that we are obliged to do when applying TDD. It is to write new code only if we already have a failing automated test, and to eliminate duplications. The rules then cast TDDs mantra, which is Red/Green/Refactor.
Red — write a simple test that obviously will fail, or cannot even be compiled. This will help us to take a baby step every time we want to develop a feature.
Green — type as less code as possible which just aims to pass the currently failing test.
Refactor — get rid of the duplication you just made in order to pass the previous test, or in other words, DRY your code.
What does it look like when you are implementing TDD?
I am currently working on an extension module of an open-source CMS which is also a part of my study in the uni where my team and I agreed to adopt the TDD style in our development process. As you can see, most if not all of my commits are granular and focused on achieving one thing at a time. The label on each commit makes it even clearer that TDD is being put into practice (I personally prefer more to use conventional commit style though, but since this was the agreement in the team, there’s nothing better than following it). Indeed, refactoring is not a mandatory ritual that comes right after we pass a test. It is only needed when duplication occurs in your codebase.
However, applying this pattern of commits is not enough to guarantee that one is doing TDD the right way. One may manipulate the commits just so it looks like a TDD pattern. Obviously, it is counterproductive with the initial purpose of TDD, and whoever performing it is just wasting their time (unless there’s another hidden purpose that needs to be fulfilled). And most of the time, it is hard to detect whether one really does TDD or not, because in the end, there would be a similar amount of feature code and test code in the repository. But one senior programmer told me, that an experienced TDD practitioner would be able to distinguish it effortlessly due to the mindset and the approach behind the code.
The thing that may hold us back from performing TDD is perhaps the confusion of what to test, or maybe the laziness to test everything, even the most trivial code that is very obvious and straightforward. There are so many arguments out there regarding this, and my take on the particular topic is to not blindly follow TDD. Flexibility is a must-have mindset and don’t let the strictness brings you too far away from the main objective of TDD. Remember that it exists to obliterate your fear during programming so you eventually become a lot more productive and are able to produce a good quality code faster. If what happens is the opposite, then there might be something wrong with your practice. Even the originator of TDD, Kent Beck himself does not write tests for things that do not tend to break, as he wrote in this forum.
To sum up, TDD is an undoubtedly well-developed style that’s still relevant up till now and aimed to be beneficial when adopted in our work. Still and all, it should not be religiously followed so please stop being that obnoxious person that dragoons others to blindly implement it. One thing that is more important is the philosophy behind its creation, which in my opinion, is more essential to be engrained in ourselves.
References:
- https://martinfowler.com/bliki/TestDrivenDevelopment.html
- Beck, K. (2002). Test-Driven Development By Example. Three Rivers Institute.