Unit Testing Source Code

[bcholmes]

I JUnit. I like JUnit. I find JUnitting to be very rewarding.

Lately, I've been interested in testing more than just the code functionality. For example, I recently wrote the following JUnit tests:

• A test that scanned all the Manifest.mf files to figure out all the .jars that are needed for my application classpath. Then it compared that to the build.xml script to see if those same .jars are included in the <ear> task of my build Ant script. We've had a bad habit of people adding .jars to the manifest, but forgetting to update the build script. Check in. Build breaks. Doubleplus Ungood. But we've at least trained our developers to run the JUnit tests before they check in, so if they forget, this test will fail.
• A test that checks the configuration of Entity Beans against a database. Basically, the test validates that all the table names and columns have been correctly specified. The problem, usually, is that this problem surfaces when you start up the application server. For me, that's irritating. It takes a minute or so to start up the server. I don't want to spend a minute waiting for the server to start. Instead, I run my JUnit test. If it passes, then I've correctly configured my Entity Bean. Takes seconds.

I've been thinking about testing source code. One of the ideas that's been in my brain is a dependency checker, kinda like what you'd get from JDepend. I care a lot about dependency management, but most of the people I work with go into eyes-glazing-over mode when I try to get them to understand the importance of package dependencies. And they will break dependencies. I'd love to build a unit test that scanned all my source code, and subsequently failed if I introduce a cyclical dependency.

And then there's a lot of the complexity stuff. If you believe McCabe, a method shouldn't have a higher cyclomatic complexity than 10. What if a JUnit test checked that?

Or trivial things. I've known too many Java developers who don't seem to realize that you can use public static final DateFormat classes in multi-threaded environments. A test that discovered such things would be a good thing.