Test-driven development (TDD) refers to the method of software-development where a test case is written prior to implement a feature. Eventually, a working test case also acts as an informal specification of the feature it purports to test.
It's a good practice as it works in a large number of cases. With a unit testing framework (e.g. JUnit, CppUnit, NUnit, ... xUnit) integrated into the development environment, after changing anything, it's particularly convenient to run the whole thing once for a minimal sanity check.
There's a pitfall though, which may result in this method to fall flat. Firstly, one must understand that the possible number of tests one may write is really large for the most trivial application. Consequently, even before the application starts attaining a non-trivial size, the number of test cases may start shooting up at alarming pace. I don't have a first hand experience in employing this method of TDD in a non-trivial development scenario, but my hunch is that maintaining such large test suites written by hand will be by definition a manual process. And that'll be a nightmare for a complex enough software. The problem of doing impact analysis of which changes impact which test case is intractable if tried manually. A small change in the interface may result in a storm of failures resulting from obsolescence of test cases.
I am inclined to think that TDD is an improvement over the largely prevalent method of developing and then writing test cases. TDD gives the developer to go into a tester's mindset interleaved finely with his development exercise. But the improvement is more psychological. It can't be hailed as a technological improvement. In the present scenario where a lot of test generation is manual, that improvement is by no means trivial. But, I feel that TDD will lose its relevance in more formal settings (probably belonging to future) where everything is either statically verified, or the test generation is completely automated from formal specification.
It's a good practice as it works in a large number of cases. With a unit testing framework (e.g. JUnit, CppUnit, NUnit, ... xUnit) integrated into the development environment, after changing anything, it's particularly convenient to run the whole thing once for a minimal sanity check.
There's a pitfall though, which may result in this method to fall flat. Firstly, one must understand that the possible number of tests one may write is really large for the most trivial application. Consequently, even before the application starts attaining a non-trivial size, the number of test cases may start shooting up at alarming pace. I don't have a first hand experience in employing this method of TDD in a non-trivial development scenario, but my hunch is that maintaining such large test suites written by hand will be by definition a manual process. And that'll be a nightmare for a complex enough software. The problem of doing impact analysis of which changes impact which test case is intractable if tried manually. A small change in the interface may result in a storm of failures resulting from obsolescence of test cases.
I am inclined to think that TDD is an improvement over the largely prevalent method of developing and then writing test cases. TDD gives the developer to go into a tester's mindset interleaved finely with his development exercise. But the improvement is more psychological. It can't be hailed as a technological improvement. In the present scenario where a lot of test generation is manual, that improvement is by no means trivial. But, I feel that TDD will lose its relevance in more formal settings (probably belonging to future) where everything is either statically verified, or the test generation is completely automated from formal specification.
