If you develop software, you should unit test. If you develop Java in Emacs, you should usein combination with . Here is some information for those of you who want to start building Java apps closer to the "right" way.
I've known about unit testing for a while now, but I haven't bothered to do it rigorously until recently. I knew the proper way to do it, but opted to do it the quick and dirty way for a good long while. You know what I'm talking about. System.out.println everywhere.
It started out ghetto. When I wanted to check something, I tossed in printlns and checked the results. Once things seemed to be working, I deleted the printlns. As I started writing more significant code, I started being marginally more rigorous. After a couple of bad experiences trying to figure out where the heck I had put some of the printlns, I started to prefix the println output with the class and method that called it. I also started to favor commenting over deleting so that I could easily go back run the same verifications.
It's surprising how long you can go using that method. Then one day, you realize that you should really grow up. JUnit is the obvious choice for unit testing in Java. It seems easy enough from the examples on the web, but the thought of setting up a whole other build process and directory structure for the tests and remembering to run them can be a bit of a barrier. Sure, you get to do the regression testing you know you're supposed to do, and you'll have a stable of tests to help you debug, but is it worth all the effort to figure out how to set it up and incorporate it into your development routine?
In comes thisfrom a book that must be a terrific Ant resource if the rest of the book is anything like its chapter on JUnit. I started out with a test package structure embedded into the regular package structure. The calendar package had a sub-package called tests. This seemed like a good idea at first. The tests were grouped and separated from production code, and there was a standardized structure for all packages - tests for any given package would be in a "tests" directory in that package. The problem with this is that I had to change my build file everytime I wanted to run another test, and my production build had all these test packages that didn't need to be there. I had to choose between a perl script to take out those packages or some fancy footwork in my build file.
After playing around with JUnit some more, the directory structure and the build file elements laid out in that chapter started to make more and more sense. A separate test source code directory with a tree that mirrors the package structure is absolutely the way to go. Tests automatically get package access, the test source is separated from the production source, and it's easy to keep the builds separate. The build file makes it really easy and convenient to run tests.
Integrated into Ant, JUnit automatically creates web reports of test results, and you have the flexibility to run the complete suite of tests, a particular test, or none of the tests. It's really great stuff. Quit being a lazy developer and go get it now. Go, go, go.
last modified // 2005.11.27 // 12:09
kstroke // projects // nerdy