Unit Testing

As always, the easiest place to start playing around with new libraries and languages is in unit tests.  I’m convinced they would be worth writing if only as an outlet for developers to try new and interesting tools, let along the code quality improvements.

DBUnit

While we can quibble over including databases in unit tests or if they are integration tests the fact of the matter is that at some point most people write a unit test that requires a database with some preexisting data.  Thats when DBUnit shines. It has the ability to use xml from a file or a string or any other type of input to clean and populate database tables with ease.  It even has some nice utilities for asserting data after a test has run.

Mockito

On the other end of the spectrum from full blown database integration is mocking. When you need to disentangle an object from its myriad of dependancies and test it in isolation mock objects come to the rescue. There are a number of solutions out there but Mockito takes the cake. To see why I prefer it to EasyMock check out their comparison. They’ve even added some niceties for BDD style testing.

Hamcrest Matchers

Since Junit 4.4, a core set of hamcrest matchers has been included with the distribution and has gone a long way to simplifying assertions by through a pseduo english DSL. For even more power you can include the whole hamcrest matcher jar and start playing with features such as asserting the contents of collections.

Apache Commons

Configuration

Most projects start with one properties file and before you know it there are two, then three, then ten and it gets out of control. You have static singletons that pull files off the class path and you’ve gone off the deep end. Thats why I say start Commons Configurations, even for that first file. Not only does it greatly simplify dealing with properties from the api point of view but it allows for pulling properties from xml, jdbc, property files, and much more. Its can even work as a simple api for dealing with xml in a jiffy.

DbUtils

These days with Spring JDBC, iBatis, Hibernate, ActiveObjects, and a host of other frameworks and libraries for dealing with JDBC its pretty easy to never have to directly touch the stuff.  However, if you find yourself in the hell which is closing a connection, session, and statement (with all the null checks and finals and exceptions and oh dear god) then Commons DbUtils is for you.  A simple close() method is provided which handles all the null checking and try catching and so on. So basic and yet so helpful.

IO

This one might be a bit more obscure but if you have ever needed to simply read the contents of a file you have no doubt been stymied by which reader gets wrapped by which buffered writer and who flushes what. Commons IO provides a beautifully simple api for file reading as well as some nice utility methods, similar to DbUtils, for closing all those annoying objects with out all the hassle.

Lang

If there was one library on my list it would come down to this or Google Collections. Commons Lang is the place for every utility method you have ever thought of writing. Every time you have though of creating a null safe version of any of the String methods, StringUtils has your back. If you have though of doing the same for Booleans then BooleanUtils is for you. Same for Object and ObjectUtils. But it doesnt stop there, StringUtils has more methods than you can shake a stick at and then there is the Builder package. The Builder package contains a Hashcode, ToString, Equals and CompareTo builder. Better yet they contain methods to build these values dynamically based on reflection. I’ve taken to making a base class from which all my domain objects inherit  that simply overrides Hashcode, ToString and Equals with the reflection based builders. Never again do you need to create these annoying methods by hand or have Eclipse generate them only to forget to regenerate when you add another field.

New Kids On The Block

SLF4J

Logging, everyone needs it. Thats probably why there are at least four major Java logging frameworks.  However, they are not all created equal. Java util logging is known to have a number of shortcomings when compared to Log4J and Commons Logging is just a facade that allows you to switch between the two more easily. Out of this mess comes SLF4J. Created by the creator of Log4J it is simply a set of interfaces that anyone can implement. The default implementation, also made by the same guy, is called logback and takes all the best of Log4J and improves on it. Moreover there are converters that route Log4J, CommonsLogging, and Java util logging to SLF4J. Never again do you have to struggle with multiple libraries and configuration files for all of your 3rd party libraries in your project. Simply drop in the converters and everything nicely flows into SLF4J.

Google Collections

Like I said before, if there were one library on my list it would come down to Commons Lang and Google Collections. If you have every used Commons Collections and cursed at its lack of type safety then Google Collections is for you. If you have ever balked at having to write List<Map<String, List<Integer>>> only to realized you have to type it all over again on the left hand side of the value assignment then Google Collections static methods such as newHashMap() are for you. If you are looking for a poor mans cache then MapMaker is for you. Finally, if you want to play around with functional programing ideas in Java look no farther than Predicate and Function and take it as a challenge to remove all for loops from your application.

c3p0

Database pooling, if you connectot to a database you need it. There are a few out there to choose from and the decision is always a bit of an argument but since Hibernate chose c3p0 as its default connection pool it has gotten significantly more attention than the other options and the prevailing winds seem to suggest that it is the way to go.

Joda Time

Not everyone has to deal with time in their programs but if you do, look no farther than Joda Time. From simple formatting to the complication of subtracting dates and everything in between, Joda Time is an easy to use api for all your date and time needs. No longer will you have deal with Calendars and wonder what exactly is a Gregorian one.

Using dbunit on any reasonably sized project ends up with an explosion of xml data set files, even if care is taken to factor out common data sets and reuse them when possible.  For the longest time this seemed an unfortunate but necessary evil of using such an amazingly useful library, but that was before I attended the Northeast No Fluff Just Stuff in April.  Before that point I had been interested in Groovy and was looking for places to add it to our code base (actually snuck it into a script that ran in the build) but I hadn’t really pondered the possibilities it provided.  However, NFJS was over flowing with talks and general love for Groovy.  Somewhere between the Groovy unit testing and the Groovy MOP talks it dawned on me.  Why not inline the xml using a Groovy builder?!

Groovy has this fantastic feature called builders which allows for very compact syntax to generate any sort of markup (html, xml, java swing, etc).  Of course the one we want to focus on is the xml builder.  By simply changing the file extension from .java to .groovy on the unit test we are already half way there.  After using Groovy’s syntax for creating xml we simply call .toString() on the underlying writer, wrap it in a new StringReader() and then pass create a new FlatXmlDataSet() with the reader as the only constructor argument.

If you are using Ant for your build you can simply wire up the groovyc task to compile all of your groovy tests and then call junit on the .class files.  If you want to get this working in Eclipse, best of luck, I was able to kinda get it working under windows xp but now that I have switched to os x the groovy plugin screams bloody murder with 64-bit java under os x in Eclipse.