Do you know what you get when you combine an iterative process, an incremental one and then add a pinch of testing? you come up with 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 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. Kent Beck stated that TDD encourages simple designs and inspires confidence. The concept is simple: write a test, write code, test it, do it again.
Here are the steps:
- Write a test that defines a function or improvements of a function. this helps the developer to focus on the requirements before writing the code.
- Run all tests and see if the new test fails. The new test should fail for the expected reason. This step increases the developer’s confidence in the new test.
- Write the code that causes the test to pass. it doesn’t matter if it is the ugliest thing you have done, that is acceptable because it will be improved and honed in Step 5.
- Run tests: If all test cases now pass, the programmer can be confident that the new code meets the test requirements, and does not break or degrade any existing features.
- Refactor code: Now put the dressing on your code, make it look fancy and be sure its readability is good.
In a few words, TDD implies: write only enough of a unit test to fail and then write only enough production code to make the failing unit test pass. Basically, you are trying to do the most with the less effort possible, using an iterative method and going step by step. Besides this, using TDD meant writing more tests and, in turn, programmers who wrote more tests tended to be more productive; furthermore as they were tackling little problems at once, they found no need to invoke the debugger.
But, be careful…
Test-driven development does not perform sufficient testing in situations where full functional tests are required to determine success or failure, due to extensive use of unit tests. since the test are typically created by the developer who is writing the code to test, the test my have a blind spot and in consequence, the program will have it too.