Test driven development (TDD) is an advanced technique which is an evolution of the test first programming concept in extreme programming.
In TDD the programmer first writes the test for a particular routine before actually writing the routine itself. naturally the test will fail because there is no working code that satisfies the test conditions.
the programmer then writes just enough code to pass the test(Adhering to SOLID, YAGNI and KISS principles).
after the test passes successfully the programmer then returns to the production code in order to refactor it by Changing the code to remove duplication and to improve the design while ensuring that all tests still pass.
this cycle is called Red, Green, Refactor and is done repetitively until the piece of software being developed is complete.
Benefits of Test Driven Development
-
The suite of unit tests provides constant feedback that each component is still working.
-
The unit tests act as documentation that cannot go out-of-date, unlike separate documentation, which can and frequently does.
-
When the test passes and the production code is refactored to remove duplication, it is clear that the code is finished, and the developer can move on to a new test.
-
Test-driven development forces critical analysis and design because the developer cannot create the production code without truly understanding what the desired result should be and how to test it.
-
The software tends to be better designed, that is, loosely coupled and easily maintainable. the tests give the developer the confidence to make design decisions and refactor at any time. This confidence is gained by running the tests frequently and after each change.
-
The test suite acts as a regression safety net on bugs. If a bug is found, the developer should create a test to reveal the bug and then modify the production code so that the bug goes away and all other tests still pass. On each successive test run, all previous bug fixes are verified.
-
Reduced debugging time.
Characteristics of a Good Unit Test
-
Runs fast. If the tests are slow, they will not be run often.
-
Separates or simulates environmental dependencies such as databases, file systems, networks, queues, and so on. Tests that exercise these will not run fast, and a failure does not give meaningful feedback about what the problem actually is.
-
Is very limited in scope. If the test fails, it's obvious where to look for the problem. Use few Assert calls so that the offending code is obvious. It's important to only test one thing in a single test.
-
Runs and passes in isolation. If the tests require special environmental setup or fail unexpectedly, then they are not good unit tests. Change them for simplicity and reliability. Tests should run and pass on any machine. The "works on my box" excuse doesn't work.
-
Often uses stubs and mock objects. If the code being tested typically calls out to a database or file system, these dependencies must be simulated, or mocked. These dependencies will ordinarily be abstracted away by using interfaces.
-
Clearly reveals its intention. Another developer can look at the test and understand what is expected of the production code.