Test Driven Development also known as TDD  is an iterative approach to developing software in the field of software engineering. In this approach ,functionality test cases are developed before development of the actual code. TDD was discovered by Software Engineer Kent Beck.

Test Driven Development TDD is a specification technique where a developer first designs and develops the automated tests for a particular functionality of an application. Then developing actual code to pass the developed test case. Using the Test Driven Development framework, new source code/production code is written only if a test fails. Test Driven Development is an iterative process that involves the creation of unit tests, programming, and refactoring.

This approach uses the concept of test-first code-latter programming concepts of extreme programming.

This approach is effective in maintaining the quality of software because it focuses on the requirements first. This in turn helps developers avoid problems such as “gold-plating”. That is adding unnecessary features and functionality to meet the developers’ expectations rather than the customers.

In this article, we will examine how Test Driven Development TDD is applied at every stage of the development cycle. You’ll learn ways for using Test Driven Development TDD as well as some problems when using it.

Why should we use test driven development?

Test Driven Development TDD promotes a test-then-code approach. In this approach, developers write unit test cases after understanding the requirement, so they create better software. Test Driven Development approach is different from normal software testing, where developers develop the source code first and then test it.

The main benefits of Test Driven Development are:

• Test Driven Development gives developers a better understanding of customers’ requirements. Using TDD, developers develop exactly what is intended to develop without any unnecessary coding.
• TDD leads to testing the implementation details while development helps to reduce bugs. 
• With Test Driven Development, functionality issues can be easily identified when the software is being developed. This allows addressing the bugs more effectively and at an early stage of development.
• Test Driven Development (TDD) helps to simplify the code and prevent unnecessary features and functionality from being added.
• Due to constant refactoring of the code, unnecessary duplication of the code is avoided.
• In Test-Driven Development (TDD) the development time reduces and productivity increases. This helps in delivering a functional piece of code to customers in a shorter period and get the feedback at an early stage.
• TDD supports evolutionary development.

Why is test driven development becoming a trend in software development?

One major reason for test driven development TDD becoming a trend is that test driven development makes a developer analyze the requirements before writing the production code. TDD leads to testing detailed specifications. This makes the production code customer oriented and bug-free.  Test-driven development finds the cracks before the client does and gives the developer time to either fix the issue or re-think the logic. Bugs are stressful so anything that can make sure there are fewer bugs is a good thing. Test-driven development (TDD) also helps to achieve complete product knowledge. Product knowledge within the team helps to reduce rework and enhances the quality of the product.

How to perform TDD?

Five steps to perform TDD process are:

1.     Create automated test cases: Developers create unit tests for a particular functionality of the software. The test case should be precise to satisfy the customer’s requirements.

2.     Run the automated test cases: The testing code from the test suite should compile and execute. This phase will ensure that the requirement is achieved.

3.     Write production code: Developers write production code, so that the automated test from the test suite passes. The production code should be simple and precise. No production code should be written beyond the scope of the automated tests. The test coverage of the production code should be 100%.

4.    Run tests and Refactor code: If any test fails, the production code must be revised for the failing test cases until the test passes. This helps to check the production code meets the test requirements and code does not break for the existing functionality.

5.       Repeat: The cycle is repeated for each new piece of functionality. Functionality and tests for the functionality should be small.

The image below represents a high-level test-driven software development approach:

What is TDD in Agile?

To understand how the Test-Driven Development (TDD) process fits into Agile, first, let us understand what Agile is.

Agile is a method of software development. It is an iterative development approach, where solutions to requirements come through collaboration between cross-functional teams. Agile processes or methods ensure a disciplined project management process with frequent feedback through frequent inspection. Agile helps to get feedback from the customers at regular intervals.

During this process, requirement change might occur during the development cycle. To deal with this TDD helps to get this feedback early and avoids creating unusable software.

Since TDD follows a test-then-code approach, the bugs get identified way ahead. So, the quality and delivery of software are not affected. Because of early feedback, bug fixes, and restoration of code, the software ensures that requirement is achieved without breaking the code.

TDD and Agile together enhance the collaboration of development teams, quality assurance teams, and customers.

Best practices in TTD or Test Driven Development

1.      Focus on customer need

Writing tests before writing the functional code enables developers/software engineers to focus on actual customer needs and helps to ensure that tests work to assure quality, not only checking the quality.

2.      Avoid functional complexity

Focusing on one functionality of a feature at a time helps the developer to keep the code simple. Writing tests for one functionality helps to verify it in all possible ways. Since TDD is a test driven development, test cases should be reviewed for completeness and correctness.

3.      Minimize the functional code

Developers/Software Engineers need to ensure only that much functional code is written which can pass the test case. In TDD, coding needs to be precise so that it achieves its purpose without any test failures. Keeping the functional code to the point helps to reduce the possibility of faulty code and duplicate code. It in turn saves a lot of time and effort. Engaging team members with good application knowledge and maintaining a repository of test cases can ensure a bug-free successful project execution.

4.      Write new code only for failing tests

Once the developers write code (new code) for one functionality, it needs to be tested. If the test fails, only then revise the functional code for the failing test cases. If the test passes then there is no need to modify the functional code and it means that the feature is already implemented.

5.      Test repeatedly

Existing tests need to run repetitively to avoid any undesired results. Tests are run before coding and after coding. Test cases should also run each time there is any change to the functional code. Once all the test passes only then the functionality is complete.

6.      Avoid code conflict

Use version control tools for check out and check in of functional code. When more developers are working on the code, the merge conflict tends to occur. Using continuous integration tools like Jenkins can avoid code merger conflicts.

7.      Pass tests before writing a new test

Focus on one function at a time. Only when all the tests pass, the developer should move to write a new test. Writing several test cases before the implementation of the functional code leads to complexity and calls for more problems to arise.

8.      Refactor only after passing the tests

Refactoring helps to improve the design of the code. Refactoring should be done only when all the test cases for one functionality pass. The tests should be re-run after refactoring to ensure there is no code break due to refactoring.

9.      Naming conventions

• Naming convention places a very important role in TDD. It helps to avoid breaking the code due to confusion between testing code and functional code.
• Test cases names should be descriptive. This helps the developers easily find the functional code’s testing code.
• At least two source directories need to be created. The functional code should be placed in src/main/java and the test codes should be present in src/test/java.
• It is easier to find tests when they are in the same package as the code they test.

Although test driven development (TDD) might be time-consuming, it is valuable for detecting bugs at the very early stages of the development thus improving the quality of the end product. Using the TDD approach, developers have more clarity about the customer needs, so they tend to have structured thinking and usually provide better results.

When should we use TDD?

TDD works great in certain scenarios. So below are the scenarios when TDD works best:

• When requirements are clear, and functions have pure logic that you need to write.
• When a function has a clearly defined set of inputs and outputs.
• When software can be broken into smaller pieces of functionality and tested in isolation.
• When the application calls for layering within it.

What are the three phases of test-driven development (TDD)?

Red, Green, Refactor are the three phases of TDD. The sequence followed while writing code is Red – Green – Refactor. Following these phases properly helps to ensure that test code is written for the production code.

Red Phase – In this phase the developer has to write a test code for a requirement against no production code. In this phase, the test code is written to fail because there would be no production code for testing. In this phase, you get a red flag from the unit test framework.

Green Phase – In this phase, the developer writes the code against the test code written in the red phase. Only that much code is written which will pass the test case. Any extra code must be avoided. After passing the test case, a new test case is written and then code is written for that test to pass.

Refactor Phase – The red phase and green phase focus only on writing unit tests and production code to pass the unit tests. But in these phases, we miss analyzing designing aspects, readability, code quality. In this phase, the developer takes care of these features. While refactoring there is no problem with missing the functionality as any refactoring lets the automated tests run again to confirm the functionality.

Advantages of TDD

Some advantages for considering TDD are:

• Reduce development costs

TDD implementation helps the developers to understand the requirements from the customers’ perspective. This helps developers to develop code with the best quality. So, the re-work reduces which in turn reduces the development costs.

• Reduce deployment time

TDD helps the developer to divide the software into multiple functional pieces. One functional piece is completed at a time and can be tested and run-in isolation. So, a particular piece can be delivered to the customer. This helps to reduce the deployment time.

• Improve Productivity

TDD approach supports writing a single unit test for an aspect of the software. Developers develop the unit test for that aspect and then production code so that the automated unit tests passes. The production code should be simple and precise to just pass the test. No production code should be written beyond the scope of the automated tests. One aspect should be complete with all tests passed before moving to another aspect. This helps to design code better and create a more extensible code with the least number of bugs.  

• Bug Feedback at an early stage

Using TDD, developers develop a functional unit and test the unit using the test suite consisting of manual and automated test cases to pass the code. These test suites can be rerun any number of times. This helps to immediately find the bug and resolve it. Also, TDD helps to get continuous feedback from customers which in turn helps to resolve customer feedback at an early stage. 

• Well maintained codebase with reduced defect rates

TDD approach implements refactoring of code at regular intervals. Refactoring minimizes the possibility of breaking the code. This in turn helps to create a well-maintained codebase.

The test-first code later process of TDD reports significant reductions in defect rates.

Common Pitfalls while using TDD

Typical mistakes which teams make while using the TDD approach:

• Individuals tend to forget to run tests at regular intervals.
• TDD supports writing one test case at a time. But individuals write a lot of test cases at a time which lets the TDD approach fail.
• Sometimes individuals don’t write tests that cover all possible scenarios.
• TDD approach will fail if all team members of the team don’t follow TDD.
• Refactoring is an important aspect of TDD. Failure to maintain a clean code and failure to clean abandoned test suites, in turn, fails the ideology of TDD.

Test Driven Development vs. Traditional Techniques

TDD	Traditional Techniques
A successful test finds several defects using TDD but feedback is received at a very early stage of development. Any change doesn’t impact many files, so requires less time and effort.	Using Traditional testing also a successful test finds several defects but feedback is received at the very last stage of development. Any change requires a lot of time and effort.
TDD covers every aspect of a requirement.	One might miss covering some scenarios of a requirement.
Regressive testing helps produce a high-quality and bug-free product.	Less testing might break the code in an unusual scenario.
TDD focuses more on writing production code to pass the written test cases (test code). The test coverage of the written production code should be 100%.	Traditional testing focuses more on writing test cases (test code) to pass the written production code.
TDD helps to maintain a short feedback loop.	Traditional testing maintains a long feedback loop.
TDD achieves 100% code coverage.	Traditional testing never achieves 100% code coverage.

The image below gives a high level difference between traditional testing technique and test driven development technique:

Software tools for TDD or Unit Test Framework for TDD

TDD is all about writing test cases before adding function definitions. So, one needs to use the unit test framework to write the unit test cases. Below are some testing frameworks and tools used to write unit test cases:

• GoogleTest or GTest: A C and C++ unit testing framework used by C/C++ developers to implement TDD. 
• JUNIT: A Java unit testing framework used by Java developers to implement TDD.
• NUNIT:  A C# unit testing framework used by C# developers to implement TDD.
• PHPUnit: A PHP unit testing framework used by PHP developers to implement TDD.
• PyUnit: A Python unit testing framework used by Python developers to implement TDD.
• RKTracer tool, Parasoft tools, VectorCast tool, and LDRA tool: Tools to auto-generate unit test cases for TDD. These tools are supported by C, C++, Java, and C#.

Acceptance TDD and Developer TDD

Acceptance TDD (ATDD): ATDD is a type of TDD, but the main difference is TDD tests focuses on performing a set of operations correctly whereas ATDD focuses more on creating bridge between customers, developers, and testers to ensure the requirements are descriptive and detailed. Using ATDD, a single acceptance test is written to fulfill one functionality of the system and then only that much source code is written which can pass the written acceptance test. Once an acceptance is passed other functionalities are tested by writing various acceptance tests. This test process is also known as Behavioral Driven Development (BDD).

Developer TDD: Developer TDD is the basic TDD where unit tests are written and only that much source code is written which can pass the written unit test. Developer TDD supports test automation. Test automation helps in regression testing using regression tests.

TDD implementation on Private Methods

Private data and private methods are implemented to fulfill the concepts of data privacy, encapsulation etc. These data and  methods can’t be directly accessed by the test code. Java and other languages use different ways to access these data and methods like inner class, reflection etc. But object oriented programming doesn’t provide any such ways to access these methods. In these cases integration tests, end-to-end tests help ensure quality of the product released.

Drawbacks of TDD

• Implementation of Complex Software

For complex products, it is difficult to break the functionality and hence difficult to calculate the test cases. Test cases can’t cover all scenarios of testing the software. This happens for highly complex software.

• Slow Process

Test Driven Development (TDD) initially slows down the development process. To begin TDD, we need to invest extra time to understand the functionality, write a test case, then run it before the actual writing of the production code.

• Design/Requirement Change

Some products tend to change the design during product development, this will force you to rework your test cases which will generate a big-time loss. TDD fails for products where there are continuous requirement changes.

• Legacy Product Impact

Test Driven Development (TDD) is very hard to implement in existing legacy products.

• Products involving User Infaces, Database, Network Configuration

TDD is very good when it comes to detailed specification but when success and failure of a product depends on testing user interfaces(UI), programs dealing with database and network configuration, TDD doesn’t perform well. In these cases, the Agile Model Driven Development (AMDD) out performs TDD. AMDD helps to create a bridge between data professionals, Business Analysts, and stakeholders.

• All the members of a team must follow TDD

Unit testing must be performed by the whole team. If all the tests are not maintained by everyone on the team correctly, the whole system can fail.

TDD for Complex Systems

In recent times, projects have changed from being simple and complicated to complex. So ancient ways of dealing with product development are no longer as effective as they used to be. Nowadays products are becoming more complex because of the growth of computing power. We want to use it to ease all our complexity.  Also, with business needs changing very frequently, the complexity is also increasing drastically.

In the case of simple and complicated products where requirements are almost fixed, the TDD framework works wonders. But for complex products, the unit test in the TDD approach fails. In the unit test approach, we bind a test case to the requirement and production code to the test case so tightly that if there is any change to the requirement tends the tests to fail. And how severe the failure would be, can’t be calculated. In complex products, where the solution to a requirement is not clear at this point, calls for multiple experimental code changes. In such scenarios unit tests fail to fulfill the requirements.

But TDD framework can still hold good for complex products by using functional tests instead of unit tests. Functional tests allow changes to the codebase because they check the functionality of the code. The Red-Green-Refactor cycle helps in solving the problems with complex products. This cycle makes the code easier to compose.

Summary

Test-driven Development (TDD) is an approach to writing test cases before writing the production code. In other words, TDD is a way to analyze through the requirements. TDD is being widely accepted by many software developers because of its proven way to ensure effective and quality software development. TDD doesn’t work wonders for complex products but when implemented properly by the whole team can solve many pitfalls of software development. TDD when accepted by the whole team religiously can help write clean, bug-free, well-maintained code that wouldn’t break at any point.