Test driven Development
According to Wikipedia:
Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards.
TDD = Refactoring + Test First Development (TFD)
Test driven development is completely turns around traditional development. In this case when go to implement new feature just ask “is existing design best suitable for implement that functionality or not.” If yes then proceed via TFD approach else refactore the portion of the design that affected by the new feature. As a result always improving the quality of design and make it easier to work in future.
Write test code before functional code. It will be done in very smaller step – “Write one test and a small bit of corresponding functional code at a time.”
Generally a programmer who code using TDD approach always refuses to write new function until a first test that fails. (Note: The function fails because yet that function doesn’t exist.) In fact they don’t want to write a single line of code until a test exists. So once the test is in place then they start work and write required production code to ensure that the test suite is passes properly.
This process sound simple but at the beginning of practicing TDD approach it requires great discipline because it is easy to forget and write functional code without writing a new code for that functional code. If you practice pair programming then your pair will help you to remind about write test first and stay on track.
There are two levels of TDD:
1. Acceptance TDD (ATDD).
@. Write a single acceptance test or behavioral specification depending preferred terminology
@. Write enough production code to fulfill that test.
ATDD specify detailed executable requirements for solution on a just in time (JIT) basis. It is also called Behavior Driven Development (BDD).
2. Developer TDD
@. Write a single developer test (sometime inaccurately referred to as unit test)
@. Write enough production code to fulfill that test.
Developer TDD specifies a detailed executable design for solution on a JIT basis. It is also called TDD.
Following UML activity diagram shows how ATDD and Developer TDD fit together.
@. Write an acceptance test
@. Implement the production code
@. Add developer TDD approach to write production code required to fulfill the ATDD test.
This requires several iterate several times through the write a test, write production code, get it working cycle at the developer TDD level
In above figure we show how to doing both. It is also possible to do either one without another i.e. do developer TDD without ATDD or do ATDD without developer TDD.
Benefits of Test Driven Development
The benefits of Test Driven Development (TDD) are as follows:
@. TDD ensures high quality code from the very beginning of the system. Developers are encouraged to write necessary code to pass the test. If test is passes then fulfill the user requirement. Keep in mind that if a method contain minimum amount of code then there fewer opportunity for error.
@. Most TDD practitioners write code that follows the SOLID principals. SOLID ensures that the developers are writing quality software.
@. TDD ensures a high degree of fidelity between the code and the business requirements. Generally requirements are written as tests. If all tests are passes then we can ensure that code meets the needs of the business. It increases developer’s confidence level.
@. TDD encourages communication with the business. To create these tests, you need to interact with the business users. This way, you can make sure that the input and output combinations make sense, and you can help the users understand what they are building.
@. TDD helps keep unused code out of the system. Most developers have written applications based on UIs and wrote methods based on what might happen. This leads to systems with large parts of code or functionality that are never used. This code is expensive. Developers give huge amount of efforts to write these codes and even though that code does nothing. Also need to maintain those unused codes. It also makes things cluttered, distracting you from the important working code. TDD helps keep this parasite code out of your system.
@. TDD provides built-in regression testing. As changes are made to the system and your code, you always have the suite of tests you created to ensure that tomorrow’s changes do not damage today’s functionality.
@. TDD puts a stop to recurring bugs. You’ve probably been in situations where you are developing a system and the same bug seems to come back from QA repeatedly. You think you’ve finally tracked it down and put a stop to it, only to see it return two weeks later. With TDD, as soon as a defect is reported, a new test is written to expose it. When this test passes, and continues to pass, you know the defect is gone for good.
@. When developing applications with testability in mind, the result is an architecture that is open, extensible and flexible. Dependency Injection is a key component of both TDD and a loosely coupled architecture. This results in a system that by virtue of its architecture is robust, easy to change, and resistant to defects.