A newer, sometimes controversial best practice these days when writing good, maintainable code is to write the unit tests for your code before writing your code. This is called Test-Driven Development or Design. I have had some good experiences with this methodology lately. I have used the nose for python and the built in prove which uses Test::Simple or Test::More in perl. Test::More is recommended by both modern and enlightened perl. While I haven’t used it yet, the BASH specific bats testing framework looks good for shell code.
Standards exist for unit tests. Perl developers have a long history of unit testing. Nose, prove and bats are all TAP compliant. Though the xUnit family is popular there are competing frameworks exist for many languages. Jasmine and others are ready to help unit test javascript code. The history of unit testing overlaps with many areas of computer science. The Mythical Man-Month talks about unit tests, first published in 1975.
The time taken to write code is arguably a savings of time overall. How can this be? This is due to work taken to clarify specifications which is required anyway. This should lead to better, more efficient code. The theory is that the much more modular code required for unit tests is also easier to understand and maintain. This theory has been validated in several research studies. The extensive regression testing can quickly identify changes that introduce bugs if the tests are run just before and/or just after a check in to a revision control system. However there isn’t quite consensus that TDD is the best way to code. What have your experiences been with Test Driven Design?
We meet at Bobby G’s Pizzeria on the second and fourth Sundays of each month from Noon to 3PM in Berkeley near the Downtown Berkeley BART station. Bobby G’s is on University Ave near Shattuck Ave. We hope you join us, join the discussion on our email list and/or join us in #berkeleylug on freenode.net by following the tabs at the top.