We’ve all done it: File|New|VCL Forms Application. Then we drop a button and a memo, double click on the button, and write some code that prints out to the TMemo. You start out just “testing something out”, but then you end up working on a routine, or maybe even a class or a collection of classes. Your “tests” are runs of the app, pushes of the button, and then looking at the output in the TMemo on your form.
Sometimes you were just trying something out, but sometimes the result actually ended up being useful.
At some point, though, you probably realized that this was a bit “amateurish” – not what “realy developers” do. Pretty soon you discovered that all the cool kids did their horsing around in Console Applications, using WriteLn to output “SUCCESS” or “FAIL” or other data, depending on how things went for testing. This worked out well – you could even set up a basic test harness to track the output by diverting the output somewhere it can be tracked.
Console applications are sexy and lean and mean. You were cool. You would eventually work what you were testing out up into a class and writing a bunch of sample code to make things work. You probably ended up with a separate unit that had a class in it and a console application that called into that unit. Way cooler that your app with the button and the TMemo.
Okay, so that is all well and good. But I’m going to argue that there is even a more sophisticated thing that we should be doing when we need to build something new – something that is designed specifically for proving that something works: DUnit. That’s what the really cool kids are doing.
If you are creating something new, and there is even the slightest chance that it will end up being real and used in production, the first thing that you should be doing is not a simple form or a console application, but a DUnit based application. This way, you can easily write tests to define how the thing you are writing should behave. You almost certainly end up writing a class (and you do put your functionality in classes right?). You can then play around with that class, add tests, and see how things work. You’ll get that beautiful green bar sliding across the DUnit Runner app, and you can continue to work up your class, add tests, and make changes with confidence as you work on stuff. Eventually you’ll end up with a tested class that you have confidence in.
It’s the ultimate way to “test something out”. (Yes, I’m trying to sneak in the back door to get you to do Test Driven Development.)
DUnit ships with Delphi, and Delphi provides a nice wizard for creating a new DUnit application. So there’s really nothing stopping you from doing DUnit first.