TDD Can Make You a Better Programmer

Maybe you’ve heard of TDD, maybe you haven’t, but that’s okay. This article will tell you about TDD and how to use it correctly and effectively to make you a better programmer.

What is TDD?

TDD is an acronym for Test-Driven Development. It is widely known in the industry due to Kent Beck’s well-known software engineering book “Extreme Programming Explained”. This is an important work that introduces a software development method: Extreme Programming.

The reason why Extreme Programming is called “Extreme” is that the idea behind it is to push good practice to the limit. And TDD is one the very good practices.

The following figure is a classic TDD model:

It can also be seen from the above figure that TDD has three points:

1. Write a failing test for the feature
2. Write the correct code for the feature to make the test pass
3. Refactor the code

Many people think that TDD is about writing tests first and then writing code. This understanding is wrong. Write tests first and code later refers to Test-First Development. rather than Test-Driven Development.

The difference between the two lies in “driving”, more specifically, there is one step difference between the two:

Refactor!

In day-to-day development, many people pass the test and think the feature is over. This is actually ignoring the “Code Smell” that new code may bring.

And refactoring can make the code better and eliminate those “Code Smell”. And it works with tests, “driving” you to write better code.

This also means that testing and refactoring complement each other. Without testing, only fearful refactoring. Without refactoring, the clutter of the code increases gradually, and the tests become more and more complex.

How to do TDD well?

If you want to do TDD well, then let’s take a look at how the masters do it.

As TDD became more and more popular, Kent Beck wrote a book dedicated to TDD called “Test Driven Development”. The main essence of this book is task decomposition.

When Kent Beck is faced with a big task, he will break it down into several small tasks and write them down on a list. Then he started writing tests, writing code and refactoring. After each small cycle is completed, cross off the completed task and start the next one.

Once he encounters any new problem in the process of doing small tasks, he will record the problem on the checklist to ensure that the problem is not lost. Then he would come back and do it. When he completes the tasks one by one, the problem is solved.

Seems easy, doesn’t it?

But in practice, most people can’t do it. Why?

The reason is that Kent Beck breaks down the tasks small enough that he ensures that the code can be submitted after each task is completed.

Upgrading a dependency version, doing a variable name change can be a separate task, and you might think it’s not worth being a separate thing. But there are benefits to this, that is:

It lets you write targeted tests and guarantees that you can stop at any time.

So what good is this?

This ensures that the content you focus on is limited, so you can think more clearly about the details of this content. For most people, the size of the problem that can be considered is limited, and it is difficult to cover everything.

And each code that is decomposed and changed will not be too much, which will keep the impact within a controllable range.

Better programmers

So TDD has brought us new software development ideas. Break down small enough tasks and keep looping the three steps of “writing tests”, “passing tests”, and “refactoring”. Not only does this drive us to improve the quality of our code, but it also gives us an increase in productivity.

So if you want to become a better programmer, start with TDD!

Full Article: Zachary Lee @ Level Up Coding