What is Test Driven Development? Or TDD?

Test Driven Development or TDD as it is fondly known in the developer circles is an important aspect of the software development process. Through this approach, it is easier to test what a specific code would perform. Test cases for each functionality of the software application is created, and when a particular functionality fails in a test, the code would be reworked on, and new codes would be created. The new code would also have to pass the test and be bug-free. The developer has to write a new code only if the automated test for the code has failed, so there will be a test case for every functionality, however small that may be. And TDD is all about designing and developing tests for every single functionality in the application. 

The name Test Driven Development indicates that it is the process of doing tests the right way that drives the software development. Hence, the process itself derives its roots from Agile methodology and Extreme programming. This process ensures that developers create and maintain code that’s resilient and long term. 

So the process for TDD would be to write the unit test first, and if the test fails, then implement the code changes. This aids in avoiding code duplication as well. The whole thing runs on writing and correcting failed tests before the actual development.  However, for theTDD to work successfully, it would be advisable to write the test cases to simple test cases. For complex business logic, it would be really tough to write a combination of test cases and achieve full success. There is a chance that you might miss out on writing some tests, so it is not an easy task at all. 

Difference between TDD and Traditional Testing

Traditional testing is more time consuming than TDD, and is based on the repetition of a short cycle of development. First the test is written from the beginning, then the program code is written, followed by the desired behaviour of the system. When the written test is passed (checking the correctness of the unwritten code’s work), refactoring of the written code is performed. 

Initially, TDD will also be time consuming, but over time, the developer will get used to it because the development process will become more structured. For example, when you hire a developer, they will decide what to write, and then how to write it. 

Traditional testing is successful when it correctly finds one or more defects. Just as the same as TDD.  Finding defects is actually a good sign because then you know you need to resolve what’s wrong and move on from there.TDD also gives you more confidence when you release the program, and ensures that it meets the requirements for which it is defined. 

In traditional testing, the focus is more on test case design, while in TDD, the focus is more on production code to verify whether the testing will work according to plan. 

TDD gives you 100% test coverage, where testing is done for every single line of code, that’s not the case with traditional testing.

When the project scope is really large, you have to be really thorough while conducting the tests. And there is a chance that the testing might become delayed, and cross the budget and time constraints. 

TDD might be hard to write, and it might slow down the development time, but it definitely would pay off in the long run. 

Another disadvantage with TDD is that the concept is hard to apply to existing legacy code. 

 It is always good to have the test to fail before you release a project, because then you will know you have run a valid test. Through TDD, you will know that your system meets the requirements for which it is designed. So the focus is more on production code for TDD, as it ensures whether the testing will work properly. And when the software meets all the requirements designed for it.

The different stages of a test driven development

There are three different stages of TDD: Red, Green and Refactor

Follow this order of steps ensures that you have tests for the code you are writing,  so you have to write the codes for only those tests that you are doing. 

The Red stage

The idea of the red stage is to make the test fail, and the most difficult phase too because th develops has to write test against no code. New developers must find it difficult because they would be confused as to what to test without having the code for it. But it is a habitual thing and with experience will become smooth. The first test is written without writing code, and to declare class and method, and the test will have compilation error. The next step would be to fix the compilation error, and execute the test to fail it. This causes the red flag.

The Green Phase

After the Red stage, the next step would be to write the code. This code will have to pass the first test. Just writing enough code to ensure that only the first test passes, is a hurdle many developers face initially. Because in the next test, it would have to fail, followed by new code to pass them. 

The Refractor Phase

In the first two stages, where the test has to first fail, and then pass it, th aim was to then get the tests to pass. But in the Refractor phase,  other factors will have to be considered like the code quality, code maintainability, code readability etc. The focus here is thus on those aspects, so the unit tests will focus on those. In the refactoring phase, you don’t have to worry about missing functionality aspect, because when the code changes happen, the test cases will automatically conform to the functionality part also.

TDD fits well into the Agile methodology

It is quite obvious that project requirements may change well into the development stage, so having TDD in collaboration with Agile development will definitely make it successful, and build projects aligned with customer requirements. With test driven development, you get an earlier feedback on the project that you can easily work on. 

It would also help anticipate and cut down on the critical bottlenecks and ensures the project moves on as intended. Developer teams can save a lot of time as the tests are created much earlier in the project development, and they don’t have to worry about extensive test scripts. 

Conclusion

Test Driven Development is a technique that is indeed time consuming, but it is valuable in the sense that it will help drive your project in the right direction by getting correct feedback about the project, and detecting bugs. However, it is a much better option than traditional testing as it requires more time and money. 

Interesting Links:

Test Driven Development: what it is, and what it is not.

More information about Test-driven development

Pictures: Canva

The author: Sascha Thattil works at Software-Developer-India.com which is a part of the YUHIRO Group. YUHIRO is a German-Indian enterprise which provides programmers to IT companies, agencies and IT departments.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.