Test-driven development: advantages and disadvantages

Test-driven development (TDD) is a development method that deviates from 'normal' development. With this method you work exactly the other way around. Normally, you first develop all the functionalities (read screens, interactions, actions, etc.) and then write tests to validate that all the code you have written works properly. If tests fail, you will adjust the code afterwards. With test-driven development you approach this differently. You start by analyzing all the requirements for the app. You then set up acceptance criteria that must be met in order to successfully deliver the app. The next step is writing tests based on the set acceptance criteria.

I can hear you thinking, but how do you write tests if you haven't written a line of code yet? That is the unique thing about test-driven development, you first write the test case and as soon as you have made it, you ensure that the test can actually be carried out. Imagine a developer wants to develop an app for keeping track of household chores. One of the predetermined acceptance criteria is that it must be possible to create new tasks. In this case, a test scenario is written in which we can create a household task. In this test, a household task is created and then saved. If we see a new household task after running the test, the test is successful. In the beginning, the test will continue to fail because no code has been written, but with this method you keep writing code until your test scenario, which has been drawn up on the basis of your acceptance criteria, has been successfully executed.

We continue to improve the code, without changing the behavior of the code, because the behavior is based on the acceptance criteria.

Let's start with the most important, which is that bugs are found early and can hardly ever make it into a release of the app. Because we start by writing the tests and then the code, everything is always tested before a release.

This actually ties in with bugs being found in time. Namely, if we develop the application test-driven, it means that releases that go to the customer are reliable and safe. All code has been tested first and every test has passed before a new release of the app is made. This not only gives the developer a nice and safe feeling, but also the customer, who knows that the code can no longer contain errors and that the app works exactly as it should.

If you use test-driven development, this means that, as mentioned earlier, there are also tests for all pieces of written code. This means that you no longer have to test a lot of functionalities manually or have them tested, this saves you time and money every release. There are of course always edge scenarios that you want to keep testing yourself, such as the interaction (UX) of the app, but the full focus can then also be on that, instead of the focus every time being on the basic functionalities such as logging in or the create a household task. 

A bug? Did they never occur in test-driven development? Unfortunately, even with TDD it can happen that a bug is found in your app. No matter how well you try to test everything, the users can sometimes be so unpredictable that a bug slips through. 

But if that bug does occur, the TDD approach ensures that this bug never occurs again. A new test is written for every bug. And now it's actually a nitpick, because everything is tested for every new release, which automatically means that this bug is also tested and therefore there can never be a release in which this test fails again. Releases are reliable and secure.

As a developer, you always strive for clean code (aka clean code). Because you write tests first and then code, it automatically means that every piece of code is written specifically for that test. This way you ensure that every piece of code has a single responsibility has. This makes your code very easy to understand and keeps development clear. This is not only good for the developers, but also for the customer. In this way, errors in the code can be quickly isolated and resolved.

Huh, what are you saying, are there any downsides? I can see you slowly drifting off, but like any method it is wise to mention the drawbacks. The biggest drawback for someone who wants to develop an app is that the project lead time is longer, the cost of development is higher and the very first release is most likely later than originally planned. This is because with this method you do not immediately start developing the app, you first start writing tests and only then write your code.

As a result, you will see less results at the start of the project, which may cause tension. But is a quick result always a better result? In fact, practice always shows that this is not the case. If many bugs are found after release, it can seriously slow down the project. 

Whenever we talk about TDD, the metaphor or simile of a traffic light is often used. We will take you with us why the metaphor of the traffic light fits so well with this method. As everyone knows, a traffic light has three colors; green, orange and red. Every color has a meaning in traffic.

? Accelerate! You can drive through here, you have priority for everyone.

? Do I brake or do I accelerate? This is the question everyone asks themselves when they see the traffic light turn orange. But according to the rules you have to stop if you still can.

? Brakes! Red means you must stop and not continue.

I assume this one memory refresher was not necessary for anyone, but he is very helpful in explaining the metaphor. Because with test-driven development we actually do exactly the same, only every color means something slightly different and with TDD we do not have the color orange, but it is slightly different.

? This is the color you will see first when you start writing the test. This is because you always starts with testing and only then writes code. You make one, as it were  blueprint of what you are going to test and then you are going to fill it in, just like an architect first makes a drawing and only then actually builds it. And it gets even better, construction is not allowed until the blue print has been approved (there they are again: the acceptance criteria). 

Because you haven't written any code in the beginning, the compiler not what it sees and will therefore return error messages. In case of an error message, the test is not successful and therefore means that it fails. Red you are not allowed to continue here.

? Once you get the blueprint of the test, you are going to make sure that red changed to green. You do this by ensuring that the test runs with as little code as possible. Below is an example.??

First we create our test with a test in it. This test is very simple, we have a list of numbers and we want to sort these numbers from high to low. Sounds easy right?

What we then do according to this method is now only to ensure that this test green without looking further at the acceptance criteria. For this we have to first one Sorter create with a function sortDesc called, which accepts a list of numbers. So what you see below is that we return the list in the correct order.

Tada! Now the test will green become. The entered list is returned as we expect it to be. This now only works for this specific scenario. So if we have to sort other lists in the future, the test will be up again red to jump. Hence the last step in the traffic light principle, which unfortunately has no color, namely refactor.

Now the last and the most important step to ensure that your app will eventually work properly (this is what everyone wants of course ;-)). Namely the refactor step. In the refactor step we ensure that the code is optimized and meets the acceptance criteria. In the simple example above, it is of course not very much, but with more extensive functionalities that have to meet many requirements, this is a fairly big step. Now if we want to make sure that our Sorter can always sort descending properly, we will have to adjust our function as follows.

We won't go into the code any further, but this ensures that any list you pass along will always return from high to low.

Test-driven development offers the possibility to develop software with the highest possible quality.  If you think of; “Hey! I like this way of working.” Then take a look at our vacancies.

Looking for the app developer who can take development to the highest level together with you? Then let's have one drinking cup of coffee.