Bits of Learning

Learning sometimes happens in big jumps, but mostly in little tiny steps. I share my baby steps of learning here, mostly on topics around programming, programming languages, software engineering, and computing in general. But occasionally, even on other disciplines of engineering or even science. I mostly learn through examples and doing. And this place is a logbook of my experiences in learning something. You may find several things interesting here: little cute snippets of (hopefully useful) code, a bit of backing theory, and a lot of gyan on how learning can be so much fun.

Friday, June 11, 2010

About Test-Driven Development

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.

No comments: