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.
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.
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:
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.
TDD is iterative, which means that is repeats the following sequence:
These steps allow structuring the work on the project. This is how a properly conducted project based on the TDD scheme should look like:
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.
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.
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!
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.
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.
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.
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.
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:
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:
Share this post: