[SourceForge Project page] [DUT home] [Getting and Using DUT] [Plans for DUT] [DUT with multiple threads]
Short answer: so when you break something you'll find out before someone starts screaming into their phone at you.
On another level, writing a test suite is a way of translating your specification into a form the build system can understand. The test suite is the specification, and code that passes the tests is known to do what you intended. If your tests are complete. Or something.
Bug tracking. Turn a bug report into a test (or encourage qualified users to submit unit tests with their reports...), and you will _know_ when you've fixed it, and know that you don't put it back.
You got me there.
I use it because it just grew as I tried to improve my programming practice.
More seriously still: maybe you just want to spend the time to learn xUnit. it's more portable. Things that other unit testing frameworks may have over DUT:
I'm doing unit testing as part of an effort to improve my programming processes. Testing keeps me from breaking random bit of my code and not noticing. This is good thing.
So how do I systematically test DUT?
Possible answer: look for Dave's Regression Test coming soon. I hope.