Your New Habit: Writing High-Quality Code Faster with TDD

I recently attended a Hackathon where I had a weird idea. Why shouldn’t I try out TDD? There’s always talk about how it benefits projects in the long run, but what about a 3-day Hackathon? Can we really benefit from using TDD? The answer is yes, but not for the reasons you’d expect. By forcing yourself to write tests first, you’ll start thinking more deeply about the problem and its design. This will change how you write code. Because in order to write tests you have to fully understand the problem what you are facing. By having an high code coverage, you most of the time can be sure that your new code will not break the old code. You gain a lot of confidence that your new code works

The Secret of TDD

The secret to TDD lies in understanding why and how you’re writing code. By writing tests first, you’ll force yourself to think about the problem before diving into production code. I know I am repeating myself here, but really this is the core reason why TDD is so difficult. Because you clearly have to define the problem first. But at the same time this makes TDD so beneficial. I learned the one thing that many people have learned before me as well. The most important thing when starting to apply test driven development, are not the tests. It is that by writing the tests first you are forced to think about your code beforehand. You have to think before you write any actual productive code. By first thinking deeply about the problem you might come to the realization that information is still missing, or that a feature is actually not needed, while at the same time ensuring high quality software.

Why Nobody Implements TDD

Despite its benefits, many people struggle with implementing TDD in their projects. Here are some reasons why:

• Writing tests can be tedious and time-consuming
• Many developers lack the knowledge to write effective tests
• Tests can be difficult to write, especially when requirements change rapidly
• Developers often underestimate the importance of testing In the end, it is a hard thing to do. This shift involves a change in your teams’ development culture. It’s something you need to start doing on your own, and then show your team the benefits. However, demonstrating those benefits can be difficult, as they are more about the style and feel of your code. At first, these changes are not obvious or easy to understand.

Was it worth it for the Hackathon?

Most definitely. We were able to develop our project much faster because we had confidence that our changes wouldn’t disrupt existing functionality. We also could quickly identify that certain features were not fully understood, thus could identify what we needed to discuss with the team. One of the side effects was that we were able to read the tests and understand what other developers were thinking when they developed the piece of code. Avoiding interrupting each other and allowing us to stay focused. By thinking first, we also avoided implementing things that were going to be not relevant for the demonstration. Increasing our speed by developing less, and focusing more on the things that really count.

Getting Started

To get started with TDD, you need to relearn how to write tests. Treat them as a specification of your code, and believe me it’s easier once you’re not forced to fit tests into existing code. Writing tests first will make test writing much easier, but it may take time and discipline to change your habits. I can only strongly recommend that you try it out, for the next task you need to implement. See the benefits for yourself and from there it just gets easier every time you apply the technique.