Mega Code Archive

Testing quality time with dunit

Rob Bracken checks out what extreme programming using DUnit can do for your application development. You have probably heard of Extreme Programming, or XP (no, I don’t think Microsoft had it in mind when they named the latest version of Windows). XP encourages you to be obsessive about testing your code and to refactor at the drop of a hat. XP and refactoring complement each other well, as you wouldn’t be confident about refactoring unless you could test the refactored system. Even if you don’t do much refactoring, however, it’s a good idea to test the system occasionally. Moreover, if you set up a series of tests that automatically test your code, you can check any later changes you make. So, if the boss’s 10 year old son has shown him how to do a Word mail merge you can add that feature, confident you haven’t broken anything somewhere else in the system. Then, when Borland releases the next version of Delphi with the latest snappy features, or the company standardises on a different back- end database, you can migrate your code to it with the minimum of fuss, fixing anything that fails the tests. Finally, when the propellor- head who programmed the vital routine that holds the whole system together leaves the company, you can still maintain it, as your changes won’t pass the tests unless the routine continues to do what it was designed to do. I’m sure you can think of other good reasons for maintaining a test suite. If you’re following XP’s rules, you’ll write the tests for a routine before you write the routine. Then, when it passes the tests, you can be sure it does what it’s supposed to do. It’s actually easier to write the code once you’ve written the tests. The quality of your code improves, you spend less time troubleshooting and fire-fighting, etc, etc (but you’ve heard these arguments before, haven’t you?). You don’t, however, have to do the full XP bit to take advantage of the benefits of automatic testing.