Test-Driven Development (TDD) is a Software Development Process where the developer writes a test first, runs the test to see if it fails and then writes a piece of code to make the test pass. In ‘Agile Coaching’ by Rachel Davies and Liz Sedley, they mentioned that developing using the TDD technique helps the developer work from outside-in than inside-out, because for each test, they consider the interface of the code before its internal logic. In ‘Test Driven .Net Development With FitNesse’ by Gojko Adzic, he mentions many advantages of TDD like building quality right from the start, validating interfaces early, providing a safety net for the code etc.In ‘Agile Testing: How to succeed in an Extreme Testing Environment’ by John Watkins, Lucjan Stapp, an assistant professor at the Warsaw University of Technology, presents a case study on TDD. The study shows that there is a learning curve for teams new to TDD. But, once the team gets used to it, the number of bugs reduces significantly.
Some teams argue that TDD confuses them and they feel more comfortable developing a piece of software and testing them robustly afterwards. But the truth of the matter is in such teams testing gets missed like waterfall projects. A common example is, a webpage was planned to be developed in a sprint of two weeks, and developers could not complete until one day before the sprint completion date. The Sales guy asks on the last day for the feature as a customer is waiting for it before making the payment. As a result, the team decides to deliver the feature without testing it. Had the test case been designed and automated, it would not have taken long to execute and verify if the code was good when completed.
For independent test teams also (irrespective of the project life cycle model), TDD can be a great tool for verifying application quality. Let’s say an application needs to be developed which writes to the database. For testing it, the tester would need to develop SQL scripts and execute to see if the application had written successfully. Following TDD principles, a tester can create SQL scripts and run the scripts before the application is developed. The script should fail the first time but once the application is developed, it should pass if implemented correctly. By doing this exercise, the tester would have understood the applications functionality thoroughly and therefore wouldn’t take too long to detect a defect (if there are any).
Do you practice TDD? If so, please share how this has been implemented. It will be lovely to hear from you.