Test-driven Development or TDD pertains to an exclusive software development process relying on repetition of ultimately short development cycles wherein requirements are actually turned into particular test cases. The software will then be improved to pass only the new tests. TDD is in contrary to software development which allows software to be included or added that is not actually proven to meet the requirements.
TDD is somehow linked to the concepts of test first programming for extreme programming which begun way back in 1991. However, more has just created general interest on its own right. Numerous programmers also apply this concept to- improve and debug legacy code created with older strategies and techniques.
Reasons to Do Test-Driven Development (TDD)
There are many known reasons why individuals are doing TDD and these include the following:
- Because TDD works the way you want it. TDD also helps in alleviating problems since the testing serves as specifications for what proper code to be written will do.
- Because codes will read like clear poetry. Since refactoring code is said to be a built in step in test-driven development, you will surely end up with cleaner codebase. Apps that are built with TDD are likely to have minimal duplication and few edge cases that are not thought through and overall, a better architecture.
- Because TDD saves you money. Individual and the industry tend to spend time that cost them bigger amount of money wasted every year. By means of adopting the TDD approach, money will be saved and more of this money can be spent on newest innovations instead.
How to Do It?
The following is the graphical representation of the lifecycle of Test-Driven Development or TDD:
- Add Test
In TDD, every new feature starts with writing a test which defines functions or improvements of these functions. These must be succinct. In writing a test, the developer must clearly understand the requirements and specifications of feature.
- Run All Test and Figure Out if New Test Fails
This tends to validate that test harness functions correctly and new test does not actually mistaken pass without needing any new code and the required feature does not exist. This vital step also assesses the test itself and in the negative; this rules out possibility that new test always passes and is therefore worthless.
- Write the Code
The next step when doing TDD is writing the code that result to passing the test. The newest code written at this particular stage may not be perfect- and for instance pass this test on inelegant way. However, this is somehow acceptable because this will be honed and improved in step 5. At this certain point, the sole purpose of written code is to successfully pass the test.
- Run Test
If the entire test cases pass, programmer can now be confident that new code efficiently meet the requirement of the test and does not in any way degrade or break any existing feature.
- Refactor Code
The code base should be regularly cleaned up during TDD. New code can now be moved from where it’s convenient to pass the test where it logically belongs. Duplication should also be removed and module, method, class and object names must clearly represent their present use and purpose as added functionality is included.
— Slimane Zouggari