TDD (Test-Driven Development) - what is it and why should you use it?

TDD stands for Test Driven Development. To put it simply - it is a kind of development process that focuses on testing. Someone who follows TDD principles will write or update test case scenarios for every change they make during development.

TDD - writing a test to not existing code

Test Driven Development is an absolute game changer in the approach to code testing. In a nutshell, this technique consists of writing tests to a not existing code. In later stages of the coding process, it requires writing code compatible with the tests and then refactoring the code.

TDD is based on the assumption, that the earlier is the bug discovered, the easier the code will be debugged. This model of producing software also is set up on the idea, that discovering all the possible ways of how would the code work and checking all the possible scenarios is the key. The whole process of creating a code should start only when they are both correct.

Code & Fix vs Test Driven Development

TDD stands in the opposition to the Code & Fix technique, also known as Debug Later Programming. Code & Fix the most intuitive way of approaching the coding process as a whole, so as an easy and basic way, it is often taught at the initial stages of the learning to code.

Debug Later Programming consists of four stages:

1. writing a code
2. attempting to run a code
3. getting results: code is valid or invalid
4. reaction: bug search and debugging

As you can see, this model is not perfect. Creating a code with the principles of Code & Fix technique causes the significant delay between coding a bug and debugging it. The more time passes between creating the invalid code and finding the problem, the more code can be build and base on it. In cases like this, debugging can be even more difficult and time-consuming.

Time is money, especially in commercial projects, when you are obliged to your client. Discovering a bug too late will result in harder debugging. Circumstances like this may also force you to ask your developers to work overtime, what will notably increase your costs of the project. However, if mobilizing your developers is not possible, or they still don’t manage to solve the problem, due to the delay, you’ll have to pay additional fees.
The worst case scenario is that your team don’t discover the bug until the product reaches the client. If the faulty product reach to your client, it will surely negatively affect your reputation.

How does the TDD work?

TDD is iterative, which means that is repeats the following sequence:

1. RED - writing a test to the not existing code
2. GREEN -  creating a simple, working code compatible with the test
3. REFACTOR - if your code passes the test, it's the time to rebuild it

These steps allow structuring the work on the project. This is how a properly conducted project based on the TDD scheme should look like:

RED - writing a test to the not existing code

If you want to add new functionality, first write a test for it. Then it’s time to run your test. As there is no implementation yet, the test should fail. 

GREEN - creating a simple, working code compatible with the test

Now it is time to write your functionality, just so it will pass your test. During this stage, you should focus on creating a basic and simple version of the code, as it will be used only to check if your idea is valid. Run your test, again – now the test should pass.

REFACTOR - if your code passes the test, it's the time to rebuild it

The fact that your code works is, of course, not enough. It also has to be scalable, follow SOLID principles and clean code guidelines. While refactoring your code you should repeat step 4 often to make sure you didn't break anything during the process.

Now... repeat those steps every time you want to add or change something in your application. Simple as that!

But do I REALLY need it? Well... yes and no.

Creating a code with use of the TDD principles may sound like a mundane, tedious task that only wastes your precious developer time. And sometimes you will be right! But other times it will serve as a powerful, time-saving technique. 

So, when to avoid it?

TDD is a complex tool, which can make the process of coding easier and quicker. However, just like any other tool, it will be helpful only under certain circumstances. Programming is not a camping, where spork (spoon and fork combined into one utensil) solves all your problems. 

When will TDD not be a helpful technique?

• When your project is really small, simple and will not grow much overtime. Writing all those tests will not bring any satisfying results, as you will be able to see all those possible scenarios in your head.
• If you don't exactly know what is the solution to your problem. In that case, it is better to sketch out your idea and code it first. That way, we will understand our problem and make sure you know how to fix it. Only then you will be able to stress test it and check borderline cases. TDD would only slow this process. However, even without TDD, refactoring and unit tests are still covetable.

TDD does not truly mean testing every single thing in your application, no matter how small. Testing trivial code consumes a lot of time and brings little to no value. It is good to be flexible while using any development process, so if you find yourself writing tests that you see no purpose in - stop testing and start coding.

And what does TDD give me?

Now that you understand when TDD is not an ideal solution - let us see what is so great about it!

TDD minimizes bugs in the app. By writing tests ahead, you will not waste time on searching for bugs later. This is a time (and sanity) saver - especially when developing more complex apps! TDD ensures a developer that every bit of the code is necessary. This means that there is no borderplate code and that two important rules, KISS (Keep It Stupid Simple ) and DRY (Don't Repeat Yourself), are obeyed.

Planned refactoring is cleaner, easier and faster, than making adjustments on the go. This one makes a huge impact during a long-time development. You know exactly where to start, what to do and if your newly written code worked as it should.

Good tests are your documentation. That means you don't have to spend your time writing dry documentation and updating it constantly. You can just show the test folder and your new team member should quickly grasp what everything does.

Practice, practice, practice…

Writing in TDD is an easy habit, once you know how to do it. To speed up learning process there are some important things you should take into account:

• Keep it small: keeping tests small will make it more readable and easier to debug. It is a common practice to test only one feature per test.
• Don't be scared of the test volume: during TDD, you will find yourself writing a lot of tests. Do not get scared of it! However, try to keep them clean - maybe by separating them into different folders depending on their type?
• Isolate your tests: it is always good to isolate your code, and that includes tests. If your tests are interdependent, they are complex and can change behavior. unexpectedly. This means that you will find yourself spending a lot of time debugging tests, while they should prevent you from debugging your code.

Summary

It is important to understand when and why you need a certain development style. TDD is one worth remembering when you are planning to develop a project, especially if they are likely to last for a long time and the process will be complexed. On the other hand, you will not utilize TDD’s advantages during some short-time projects, which are not likely to be developed in the future - this is when you should not take the TDD into consideration.

Do you need the support of professional application testers? Count on Softnauts! You can find out more about our offer below:

•  Application testing.