First, read Ted Naleid‘s great writeup. He encountered many of the same issues I found and documented them in great detail. Plus he has a list of other reference pages.

Second, as Ted mentions, there are problems using a base class for tests. This is especially true if you have JUnit annotations in the base class like @Before. Instead, turn your base class into a generic POGO and then use the @TestMixin annotation to include it in your tests.

class MyAppTestSupport {
    //...useful common properties and methods here....
}

Then in your test class:

@TestFor(MyDomainClass)
@TestMixin(MyAppTestSupport)
class MyDomainClassTests {
    //you can access the properties and methods from MyAppTestSupport here just as
    //if they were part of your class
}

This makes it a little harder to jump to routines in the mixed-in class in an IDE (at least Intellij gets a bit confused), but the tests will run consistently.

Another example is yet another good post by my friend and coworker Jeff Erikson detailing his research into problems with Grails config options getting wiped during integration tests.  I had been meaning to write up a note about how the GrailsUnitTestCase class hides the true config settings, so you don’t want to accidentally use it in integration tests.  Jeff took my little tip a lot farther with his post.  Thanks, Jeff!

But then Groovy 1.6 came out and I saw that the team had added some very cool annotations to make categories even more powerful and easier to use. (See InfoQ for a great write up of the 1.6 features.) Okay – you don’t improve a dead feature, so what was I missing?

This past weekend I got a chance to ask the person from whom I first learned about Groovy, Scott Davis. His Blue Pill and Red Pill talks at NFJS were what first got my mind churning about the possibilities that Groovy opened up. Before sitting in on another of his talks at the most recent NFJS conference this past weekend, I asked him why one would use categories in a DSL rather than modifying meta classes? His answer told me that I was asking the wrong question. The strength of categories is in scoping – modifying behavior for a limited period of time. The primary example he gave was for unit tests. A category can short circuit certain behavior (like retrieving info from a DB or from a file) to make it easier to test certain behavior in isolation. This makes a lot of sense. Mocks/stubs have their place; they are useful when you need to work with an object in a very limited sense – just a few calls. Then there are times when you want a real object doing 95% of what it is supposed to do, but you want to take over in just a few situations to be able to insert custom behavior. e.g. in a unit test when you want to short circuit network or file-based activity or you want to purposefully force an error condition.

It so happens that I really need to improve the unit tests for some network-based components in the ETL system that I work with. The primary one is called GetHttpContent, so you can imagine that unit testing it can be a pain. I’ll give Categories a closer look to see if they can help me out. Unfortunately, I have to wait until we finish shifting to a our new project structure because right now there are so many dependencies in the primary project that if I work on a groovy file in that project in Eclipse I lose ~20M of memory every time I edit it. But the limitations (and benefits) of the Eclipse groovy plugin can wait for another post.