Typed variables in an untyped world

First, off, I’m a static type person.  Sorry, but I like me some static typing. It makes me feel warm and squishy.  It makes my IDE more useful.  I can refactor an entire code base and go to sleep and not have nightmares.

Moving on, I’ve been using Groovy for unit testing a lot lately and have decided something. I like it. Its really nice to not have to deal with exceptions and be able to create lists and maps inline.  Closures kick butt.  Its really nice and easy. However, the lack of types that enable some of the cool things bug me, but they don’t have to.

Because groovy is a dynamic language you don’t have to provide the type of any given variable. This can be good and bad. Its sometimes convenient when you don’t know or don’t care what the type of a variable is.  However, in most cases, when you do know what the variable type is, it can be helpful to put type the variable.

// untyped, but it is really an ArrayList
def someVariable = ["1","2","3"]

// same idea but now you know the type
List someList = ["1","2","3"]

Now, of course, you could have deduced the type of someVariable given its assignment, but apparently your IDE is not that smart, at least Eclipse isn’t. Especially if its one of my types and not a built in type. One of the main reasons that I type variables is that if you explicitly type them, Eclipse can do auto completion on the method names of your variable.  If you use def to declare your variable Eclipse only gives you the default GroovyObject methods.  Not the best.

Also, providing types with method signatures makes it FAR FAR FAR more obvious what you are expecting of your caller.

Consider a method with the signature:

def someMethod(def thing1, def thing2, def thing3){
...
}

Mmmmmmyeah. I have no idea what to pass to that thing. I also don’t know what its going to give back to me.

Don’t get me wrong, there are times when you don’t know some of these things or its more convenient not to declare them statically, but I have found that if you actually know at compile time what something is going to be, you may want to grease back your hair with your back pocket comb in your black leather jacket and stick it to the man with a quick def, but you from two weeks in the future and the next guy to read your code will be much happier if you throw a few types in there.

Groovin' Up Your Database Tests

While TDD proclaims the gospel of fine grained tests and a healthy dose of mock objects, at some point, interaction with a database becomes inevitable.  Luckily, there is DbUnit to assist us.  DbUnit is a fantastic framework which allows for painless setup of database data sets, ensuring repeatable, self contained unit tests. However, there are already plenty of tutorials on the subject.  Instead, what I want to talk about is the dark side of dbunit… xml.

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.

Follow

Get every new post delivered to your Inbox.