Fast and reliable coding through Test-Driven Development

If I’d tell you that there is a way to be more productive. At the same time, that documents your code along the way and adds value right away. Something that prevents you from wasting time and helps you focus on providing effectiveness to your code. If I’d tell that you could gain confidence and that it would offer all that at no cost. Would you ear?

I’m a Franck and I am a frontend developer with ~12 years of experience. I saw practices and tools pop-ing here and there since then. This is a fast-moving market. But in this market, there is something that stayed stud and changed my way of coding. And it did for the best: Test-Driven Development.

The beauty and the beast

In my experience, most developers (including me at a time) write code before testing. This was my case not that long ago. But often, writing code before testing is insurance having to break the code afterward to make tests pass. This is like coding to write tests. Let’s take a moment to realize the awkwardness of this sentence.

Let me ask you: Where is the value here? I believe we write code to provide value to customers. We do it for us as well, to be able to come back to our code later and recall faster what it’s doing with as little pain as possible. I admit I have a very bad memory. This is in my case really saving me to have tests written.

I don’t want to be dogmatic, but I’m convinced writing tests helps a lot. Test-Driven Development helps a lot more. Test-Driven Development became a daily routine for me. Not to satisfy my ego with nice coverage scores. No. Just to write less cluttered and clearer code. I like simplicity a lot and effectiveness much more. What feels obvious and clearly feels safe to me. I like to understand exactly where I’m going and where I come from.

TDD helps me gain confidence in the fact that what needs to be done will be, in the simplest possible manner. I hate coding features that “maybe” will be used later. This is a waste to me, of time and energy. But moreover, a waste of value.

But what is Test Driven Development? As its name involves, it is the practice of writing tests first, then code the related feature. Extreme Programming popularized it. In short, it implies writing tests that fail, and then fix them by coding the related feature. Nothing more, nothing less.

TDD involves writing more valuable code

Here is a story: I used to rush to my IDE to code a feature, having in my mind the business needs. I coded it with no tests at first. After a while in my spaghetti code, I decided to write a bunch of tests… failing. And lose time fixing my tests, and break the code I had done so far. I wasted time creating something complex and often cluttered.

Does this sound familiar to you?

The fact is that when rushing to code it’s easier to put out of sight the business value of what you have to develop. It results in spending time tweaking and creating poor valued or cluttered code. This is a waste for you, and worst, for your customers.

In TDD, when writing tests first you are future-proofing what you have to do. You write your first test, simple and atomic, detached from implementation details. Pure. You run it, it breaks. Now you fix your test writing the associated code. It passes. You repeat the procedure.

This is a neat and smart way of doing in my opinion. Your implementation is simple: it just works! It fills the business needs making you create the simplest possible code. It gives you confidence, more than ever before. In the end, you develop features faster, you don’t waste time in writing anything but valuable code. It gives you confidence about the effectiveness of what you are coding.

TDD is simple but is a habit to gain

TDD principle is deadly simple: it is one of the simplest concepts to understand. But like any habit, it needs practice. No framework, no tool other than the ones you use every day. Yet, the human brain likes what it’s used to. He loves comfort. Like any habit, it takes time to integrate TDD.

TDD forces you to consider a problem in a way that feels unatural. It challenges you to think before and not during the feature development session.

It forces you to consider the end of what you’re about to develop before having started to tap a single line of code in your IDE. In the beginning, it felt awkward to me. But after one day of coding or so, it felt obvious. I acquired the habit in less than a week. And I can assure you it surprises me for the best. I wouldn’t code the same way ever after. I grew as a software developer. This was one of these “aha moments” you sometimes have in a career.

But TDD involves knowing … testing tools

I could argue that coding involves knowing a coding language and algorithmic. The same goes for testing: mastering (or at least knowing) a testing tool that satisfies your needs is mandatory.

Can you imagine a surgeon who would tell you that he will operate you with a fork because he doesn’t know the scalpel? Would you put trust in him? Of course no. You expect him to wash his hands and know what he is doing. Bear in mind that clients that give you money to build their projects expect you to provide the best value. In my opinion, testing is not an option, it’s a duty as a professional developer.

There are technological “golden nuggets” in this area. My advice: invest time learning at least one testing framework. This will save your days (and career).

Starting practicing TDD

If you’re still here so far, chances are you might consider TDD as a new habit. If so, I would recommend you try with your next feature. Start small and identify what you have to achieve, what are the boundaries.

Next, write it down in form of tests. Describe how the piece of software should work, what it’s expected to do, and what it shouldn’t. This will help you to nail down what you have to do. No more, no less. Run your test. Then, solve them. Adjust, refactor to make it pass, and start over.

It’s like creating mini-puzzles with business rules that you will solve later. It’s really fun :)

Conclusion

TDD changed the way I apprehend my work. It forced me to think right before coding. It allowed me to become a better and more productive developer.

I hope you enjoyed this post. Feel free to share your opinion either you practice TDD or not, this interests me to know. In the meantime, enjoy this Commit Strip ;)