Once upon a time, a young woman had plenty of projects and passions and was a bit hyperactive. She didn’t enjoy talking about her life and wondered how she would write this post.
Among her early dreams were learning many things about science and software engineering. She started with biosciences (which, by the way, are fascinating — nothing is more complex and well-crafted than the human body) and then decided to continue with software engineering. However, the software engineering program she completed only lasted one year (6 months of classes and 6 months of internship). Of course, this was simply a doorway to the world she was eager to discover.
Not having much knowledge or experience in IT, she was (and still is) looking for principles, good practices, methods and tools that would allow her to learn and produce clean code. Among these tools was TDD.
TDD is a development tool that advocates writing the tests before the production code. Kent Beck invented it. And you know what? It’s truly deeply delightful ;-) (this sentence sounded a lot better in my head in French, by the way). In this article, I will talk about my personal experience with TDD: the beginnings, the pros and cons, and some ideas for setting it up.
The Beginnings
In the beginning, I saw the theoretical interest of this tool and was fascinated by the concept (I found it very clever). But, on the other hand, it slowed me down a bit and was a little complicated. I tried it for the first time towards the end of my first year as a software developer, in a fairly complex project in terms of business, technologies, and challenges. Needless to say, TDD was not the only thing my head had to process! Consequently, I used it when I was not overworked and as often as possible. Moreover, the vast majority of developers on this big project did not use TDD. Thus, it was sometimes difficult to apply it in this context, but it was definitely out of the question to quit. I saw its potential and knew I had to persevere.
After this first year of experience in software development, during which I learned a lot and gain some experience with TDD, I decided to take time for my personal projects. And then, everything changed. By working on a project from scratch with full latitude, I could use TDD more readily.
Therefore, after a good night’s sleep, I decided to start my project by writing a test. It was so beautiful. At that very point, I understood several benefits that TDD could provide.
Pros
Expressing the Business Rather Than Doing an Implementation
It allows focusing on the business rather than on implementation.
Working by Units and Being More Efficient
We only do one thing at a time and thus are more efficient. Contrary to what I thought at the beginning, I quickly realized that TDD allows us to go faster. Indeed, we don’t ask ourselves twenty questions at a time to create the best design. Of course, I am not saying that we shouldn’t think anymore — thinking is an essential part of our job as software engineers. However, TDD allows us to ask ourselves even more relevant and targeted questions, one feature at a time.
Building a Relevant Test Harness
By starting with tests, we build a relevant test harness. Indeed, the tests we write cover real business needs. As a result, this harness ensures easy and quick detection of regressions during the addition of new features or refactoring, with unit testing being the least expensive in terms of implementation and providing an extremely short feedback loop.
Gaining Confidence
Using this tool, I know I develop exactly what I need to, which is not negligible, letting me gain confidence in my code.
Avoiding Bad Design
TDD lets us know when our design is bad. Indeed, if we can’t test our codebase, it means that our design is no longer adapted, or has never been. Therefore, it is a signal to simplify it and tailor it to our needs. For example, if we have to mock a behaviour to test another that depends on it, it probably means that our classes are strongly coupled. Furthermore, decoupling classes makes a system more maintainable (i.e. changeable and extensible).
I also noticed the design emerging from TDD was clean and elegant, as a result of the tool’s overall benefits: focusing on the business, performing one thing at a time, and gaining confidence.
Cons
Currently, I don’t see any. Unfortunately, TDD is regularly misunderstood and perceived as a waste of time. This false impression probably stems from the required adjustment period, which may vary for each developer. Nevertheless, TDD proves to be a good investment that deserves consideration. But how can we set it up?
Setting It Up
The way to set it up in a given project depends on its context. However, I will share some ideas here.
Start With Small Goals
Being ambitious is great, but it’s hard to climb to the top of Mount Everest on your first time without stopping. In the same way, when setting up TDD, we should properly define and measure our goals from the beginning. For example, it could be as simple as encouraging all team members to use TDD a few times a week to become familiar with it gradually.
Do Not Rush or Get Discouraged
From my experience, it is counterproductive to try to assimilate the tool and judge whether it is suitable in a few minutes. Indeed, if someone judged us in two minutes, their perception would not necessarily be relevant or complete. It is crucial to take the time to know, understand, and properly use the tool.
Do Not Consider It as Something Outside Developments
Like refactoring, TDD should be a part of our work. It should not be something we need permission for, but an integral part of our job. Consequently, we must account for the adjustment period in our estimations, hence the importance of starting with small goals. After the adaptation period, estimates will likely decrease. Indeed, TDD ultimately makes us go faster for the reasons mentioned above, and we no longer have to factor in extra time.
Have Good Communication Within the Team
Don’t hesitate to talk about it often. Different perspectives will enrich the experience.
Nevertheless, remember my advice n°2: don’t get discouraged in the process.
Conclusion
TDD is a development tool with many advantages, including clean design and fewer bugs and regressions. It is not necessarily easy to identify these benefits at first sight, but you should not abandon the ship because the journey is worth it.
Thanks so much for reading; I hope you enjoyed it :-)