The grails documentation does an OK job of describing some of the new features, but there really wasn’t anywhere that I could find that had a comprehensive list of changes you should make to your code when migrating from grails 1.3.X to 2.0.X.

This blog post is the list of changes that I wished I had when I started to migrate our code.

I found these pages helpful in figuring things out:

• The Grails 2 Testing Documentation
• Peter Ledbrook’s “Upgrade to Grails 2″ blog post
• The Grails 2 “Upgrading From Previous Versions of Grails” section of the user guide.
• Rob Fletcher’s Upgrading to Grails 2: Part 1
• This google plus thread on people’s experiences upgrading to grails 2
• GRAILS-7617 – TestFor(ControllerClass) annotation doesn’t provide renderArgs

The company I’m consulting at made a large investment in unit testing in the grails 1.2/1.3 days with 500-600 unit tests that heavily leverage custom extended base classes, `Mixin`s, and the grails 1.3 way of doing unit testing. This investment helped us keep most of our testing quick in unit tests, but has made this the most painful grails upgrade cycle I’ve been through (more painful than the grails 1.0->1.1 upgrade, which was the previous worst).

There have been surprisingly few changes to the actual production code to get things going, the vast majority of changes have been in how unit testing works.

General Test Upgrade Tips

• If you use an IDE with a debugger, it’s very useful to have a separate copy of your code that works against grails 1.3.7 so that you can have 2 instances of IntelliJ and can step through line by line in each codebase to see where things diverge.
• Methods with @Test, @Before, and @After MUST be declared public void or else they won’t be picked up
• I had real problems with using the new grails annotations (like @Mock) while extending a custom super-class, I haven’t dug to the bottom of this yet, but the grails annotations seem to have trouble with class hierarchies, avoid them if possible
• To that end, if you use the new grails annotations (like @TestFor), you MUST remove the old extends GrailsUnitTestCase
• Integration tests should also never extend GrailsUnitTestCase, they should instead extend GroovyTestCase and just use assert
• I’ve hit a number of test pollution issues when refactoring my code, where one test hasn’t properly cleaned up after itself affecting other tests downstream. If your test passes in isolation, you’ll need to run the tests in the same order as grails test-app does and slowly take out tests till your tests passes. Then you know which test is causing the pollution. The grails 2 test runner doesn’t show you the test order, but you can get it by setting a breakpoint in the JUnit4GrailsTestType.doPrepare method (line 54 as of grails 2.0.3) and executing this in your IDE: testClasses.name.each { println it }. Then you can take that list, join it together into one line and prepend grails test-app on it to run them in order.

Another way to get the in-order list of test classes from the test reports after a failed test using a little grep and sed:

grep testsuite target/test-reports/TESTS-TestSuites.xml | grep -v testsuites | cut -d\  -f8-9 | sed -E 's/name="(.*)" package="(.*)"/\2.\1/' | grep .

Mocking Class Methods by mucking with the metaClass

Groovy is now more stringent on closure arguments matching the type signature of a method it’s meant to mock. If the method you’re mocking types it’s variables, you need to match that with your closure.

grails 1.3.x:

MyDomain.metaClass.'static'.executeUpdate = { theQuery, theParams -> return}

Grails 2.0.x:

MyDomain.metaClass.'static'.executeUpdate = { String theQuery, Collection theParams -> return}

Otherwise it won’t find your closure and will still call the regular method you’re trying to mock. Put a breakpoint/println in your mocked methods to ensure that they’re being called by the code under test.

Unit Testing Domain Classes in Grails 2

mockDomain

grails 1.3.x:

class MyTests { 
    ...
    mockDomain(Person)
    mockDomain(Vehicle)

Grails 2.0.x:

@Mock([Person, Vehicle])
class MyTests {
   ...

If you’ve given mockDomain instances to save, you’ll need to save them manually now.

grails 1.3.x:

mockDomain(Person, [new Person(name: "Bob")])

If you keep the old style of domain mocking through mockDomain you need to ensure that you aren’t calling it twice on the same class (say in setUp and then again in a test method, or in a superclass and a subclass). This causes really hard to find test pollution errors downstream with the grails 2.0.3 code. It appears that it’s messing with the metaClass again and re-mocking it, but then when the test is done not fully cleaning up after both metaClass modifications. I consider this a bug as mockDomain should be idempotent; if you’ve already mocked a class calling mockDomain again shouldn’t remock the class, but this is what we have now.

Grails 2.0.x:

@TestMixin(GrailsUnitTestMixin)
@Mock([Person])
class MyTests {
    ...
    @Test public void testPerson() {
        new Person(name: "Bob").save(failOnError: true)
    ...

One caveat is that validation is now enforced on these objects, you can either pass in validate:false on the object, or use the grails BuildTestData plugin to create your valid objects:

@TestMixin(GrailsUnitTestMixin)
@Build([Person])
class MyTests {
    ...
    @Test public void testPerson() {
        Person.build(name: "Bob")
        ...

The Build Test Data plugin has recently been enhanced to work with grails unit tests, and I recommend using it’s @Build annotation in place of @Mock in pretty much every case. It just makes things so much easier by building fully valid objects automatically for you.

Controller Unit Tests in Grails 2

mockConfig

grails 1.3.x:

mockConfig """
    grails.foo.bar='baz'
"""

Grails 2.0.x:

grailsApplication.config.grails.foo.bar='baz'

mockParams

grails 1.3.x:

mockParams.foo = "bar"

Grails 2.0.x:

params.foo = "bar"

So you can replace all mockParams with just params.

mockFlash

grails 1.3.x:

assertEquals "Expected Message", mockFlash.error

Grails 2.0.x:

assert "Expected Message" == flash.error

So you can replace all mockFlash with just flash.

renderArgs and redirectArgs

The very useful renderArgs and redirectArgs mock objects are gone in grails 2.0 and I find the new way of testing without them to be harder than it was.

renderArgs.view

grails 1.3.x:

assert 'edit' == renderArgs.view

Grails 2.0.x:

assert view.endsWith('/edit')

redirectArgs

grails 1.3.x:

assertEquals 'person', redirectArgs.controller
assertEquals 'show', redirectArgs.action
assertEquals personInstance.id, redirectArgs.id

Grails 2.0.x:

assert response.redirectUrl.endsWith("/person/show/${personInstance.id}")

(or just use contains or .split('/') to find parts of the url)

renderArgs.model

grails 1.3.x:

assert renderArgs.model.person.id == person.id

Grails 2.0.x:

assert model.person.id == person.id

This seems to work unless you’re rendering a template in your controller rather than a view. In that case, the model isn’t populated and cannot be accessed as far as I can tell. This is documented in GRAILS-8659 which is marked as “Not a Bug”, something I disagree with as the workaround is much more painful.

The workaround, per Graeme Rocher on that ticket is to mock the template rendering:

views['/test/_bar.gsp'] = 'Hello ${name}'
controller.renderTemplate()
assert response.contentAsString == "Hello John"

Where controller:

def renderTemplate() {
    render template:"bar", model:[name:"John"]
}

The naming convention of what you set in the map should be in the format “/person/_editAddress.gsp”, where you’re in the PersonController and the template name is editAddress but there were a few situations where I had trouble getting this right.

If you want to be sure what value to set the path to in the views map, set a breakpoint in RenderDynamicMethod.java around like 319 where it does this check:

String templateUri = webRequest.getAttributes().getTemplateURI(controller, templateName);

The value of that templateUri is what you want to set in your views map.

redirectArgs.params

grails 1.3.x:

assert "bar" == redirectArgs.params.foo

Grails 2.0.x:

// strip off everything up till the ? that marks the start of the query string
def params = WebUtils.fromQueryString(response.redirectUrl.find(/[^?]*$/))
assert "bar" == params.foo

gross. This really should be better and usability has regressed on this.

mockResponse

grails 1.3.x:

assertEquals 404, mockResponse.status
assertEquals "foo bar baz", mockResponse.contentAsString

Grails 2.0.x:

assert 404 == response.status
assertEquals "foo bar baz", response.contentAsString

So you should be able to find/replace mockResponse with just response

mockLogging

grails 1.3.x:

mockLogging(Foo)

grails 2.0.x:

In many cases, this can simply be deleted. If it’s either the class under test (the class you are doing a @TestFor on) or something you’ve already got in a @Mock or a @Build class level annotation, it already has logging.

For those classes that need logging, but are not already mocked, you can use the grails.test.MockUtils.mockLogging static method. Just add this static import to your class to get the same behavior:

import static grails.test.MockUtils.*
    ...
    mockLogging(MyService)

If it’s a collaborator that isn’t already mocked out, you can use the mockFor method as described in the mocking collaborators section of the grails user docs.

def foo = mockFor(Foo, true) // true here is "loose" mocking, otherwise you need to `demand` method calls for them to not fail.

Overall, I’m much happier with grails 2.0. It has a number of great features and speed improvements that make it a worthwhile upgrade. I complain above about a few places where I think testing is not as easy as it was, but most of these could be remedied with a few patches to grails-core.

Grails will helpfully inject fully autowired Spring service beans into my test if I ask for them. Unfortunately, if I change the metaClass of the injected service, that change persists beyond where we want it to:

class MyService {
    def myMethod() { "unmodified" }
}
 
class MyServiceTests extends GroovyTestCase {
    def myService  // injected automatically by spring/grails
 
    void testOne() {
        myService.metaClass.myMethod = {-> "modified" }
        assertEquals "modified", myService.myMethod()
    } 
 
    void testTwo() {
        assertEquals  "unmodified", myService.myMethod() // WTF!  Returns "modified", pollution from first test
    }
}

Grails services are Spring “singleton” objects. They’re not true singletons though, singleton’s are just cached in the application context and returned whenever getBean is called.

Historically, if I wanted to mock part of my service manually, I’d need to “new” up my own instance of the service and manually inject any dependencies that the service might need to function. This is both painful and fragile, if the service adds or removes dependencies, chances are that the tests are going to break.

I realized that if I could ask Grails/Spring for a new instance of the “singleton” service that I could muck with it all I wanted in my test without worrying about polluting other tests with my changes. After some digging into the grails spring support, I came up with the following method that could be added to an integration test (or integration test base class):

// spring "singleton" objects really aren't they're just cached by their application context
def getNewSingletonInstanceOf(Class clazz) {
    String beanName = "prototype${clazz.name}"
    BeanBuilder beanBuilder = new BeanBuilder(ApplicationHolder.application.mainContext)
 
    beanBuilder.beans {
        "$beanName"(clazz) { bean ->
            bean.autowire = 'byName'
        }
    }
 
    beanBuilder.createApplicationContext().getBean(beanName)
}

This method uses the BeanBuilder to construct a temporary ApplicationContext with the Grails mainContext as a parent so that other dependencies can be resolved. This method won’t work if your service has changes to how it’s wired up and configured by spring, but the majority of Grails service classes are simply autowired byName.

Here’s a more detailed example of use. Given this service:

package com.example
 
class MyService {
    def injectedService
 
    def serviceMethod() {
        return otherMethod()
    }
 
    def otherMethod() {
        return "original value"
    }
}

I’m able to generate per-test autowired instances of my service and mock out otherMethod without polluting other tests (or the Spring injected version of the bean):

package com.example
 
import grails.spring.BeanBuilder
import org.codehaus.groovy.grails.commons.ApplicationHolder
 
class MyServiceTests extends GroovyTestCase {
    def myServiceInstance  // our new
    def myService // spring injected version
 
    protected void setUp() {
        super.setUp()
        myServiceInstance = getNewSingletonInstanceOf(MyService)
    }
 
    protected void tearDown() {
        super.tearDown()
    }
 
    // spring "singleton" objects really aren't they're just cached by their application context
    def getNewSingletonInstanceOf(Class clazz) {
        String beanName = "prototype${clazz.name}"
        BeanBuilder beanBuilder = new BeanBuilder(ApplicationHolder.application.mainContext)
 
        beanBuilder.beans {
            "$beanName"(clazz) { bean ->
                bean.autowire = 'byName'
            }
        }
 
        beanBuilder.createApplicationContext().getBean(beanName)
    }
 
    void testNewSingletonInstance() {
        assertNotNull myServiceInstance // created uniquely for this test in setUp
        assertNotNull myService         // spring injected into integration test
 
        assertNotSame myService, myServiceInstance
 
        // we've got unique instances of MyService, but both are injected with the same singleton dependencies
        assertSame myService.injectedService, myServiceInstance.injectedService
    }
 
    void testMessingWithMetaClassDoesNotAffectOriginalSingleton() {
        myServiceInstance.metaClass.otherMethod = {-> "new value" }
 
        assertEquals "new value", myServiceInstance.serviceMethod()
        assertEquals "original value", myService.serviceMethod()
 
        def anotherInstance = getNewSingletonInstanceOf(MyService)
 
        assertEquals "original value", anotherInstance.serviceMethod()
    }
}

Using this technique lets you leverage Spring’s autowiring in your tests, but also gives you the flexibility to override areas not under test to improve test readability and maintainability.

The invokeMethod method gets called by groovy’s MOP for every method call that happens on an object. If we add our own version, we need to make sure we keep a reference to the original metaClass so that within our invokeMethod, we can still get access to the other methods that we want to delegate to.

class Foo {
    def bar() {
        println "in bar"
    }
 
    def baz(String name) {
        println "in baz with $name"
    }
}
 
 
 
def decorateMethodsWithLogging(clazz) {
    def mc = clazz.metaClass
 
    mc.invokeMethod = { String name, args ->
        println "before $name, args = $args"
        def result = mc.getMetaMethod(name, args).invoke(delegate, args)
        println "after $name"
        return result
    }
}
 
 
decorateMethodsWithLogging(Foo.class)
 
def f = new Foo()
f.bar()
f.baz("qux")

prints

before bar, args = []
in bar
after bar
before baz, args = [qux]
in baz with qux
after baz

When you’re trying to do TDD and want to run all tests before pushing your code out to the shared repository, this length of time can really bog you down when it happens a number of times per day.

There are a number of tests that we need to go back in and refactor to be faster, but I wanted to see how much of a boost I could get by running unit and integration tests in parallel.

With 2 threads (one for unit, one for integration) the best case would be taking 50% of the time that it takes to run serially. That would only happen if my unit and integration tests took the same amount of time to run. For my tests, I was able to get a 39% speed improvement (with the integration tests taking a bit longer than the unit tests).

Here’s the script:

(just save it as splitTests.groovy in your path and make it executable, then run it in your grails project dir)

#! /usr/bin/env groovy
 
Map exitStatuses = [:].asSynchronized()
 
def currentDir() { 'pwd'.execute().text.trim() }
 
def getGrailsPropertyArgs(group) {
	def testDir = "${currentDir()}/test-$group"
	[
	    "-Dgrails.work.dir=${testDir}",
	    "-Dgrails.project.class.dir=${testDir}/classes",
	    "-Dgrails.project.test.class.dir=${testDir}/test-classes",
	    "-Dgrails.project.test.reports.dir=${testDir}/test-reports"
	].join(" ")
}
 
synchronized out(group, message) {
    println("${group.padLeft(12, ' ')}: $message")
}
 
[
        integration: 'integration:',
        unit: 'unit:'
].collect { testGroup, args ->
	Thread.start {
		def command = "grails ${getGrailsPropertyArgs(testGroup)} test-app $args"
		out testGroup, command
		exitStatuses[testGroup] = command.execute().with { proc ->
			proc.in.eachLine { line -> out testGroup, line }
			proc.waitFor()
			proc.exitValue()
		}
		out testGroup, "exit value: ${exitStatuses[testGroup]}"
	}
}.each { it.join() }
 
def failingGroups = exitStatuses.findAll { it.value }
 
if (!failingGroups) {
	println "All tests were successful!"
} else {
	failingGroups.each { failingGroup, exitStatus ->
		out(failingGroup, "WARNING: '$failingGroup' exit status was $exitStatus")
	}
	System.exit(-1)
}

The script is pretty simple. It creates one thread for unit tests, and one for integration tests. It then creates a grails test-app command that includes a number of grails system properties necessary to define unique target and working directories so the threads don’t step all over each other.

As the threads run, they spit their output to the command line with a prefix on each line showing which thread it came from, ex:

...
 integration: Running test com.bloomhealthco.domain.ProductTests...PASSED
        unit: Running test com.bloomhealthco.domain.QuestionUnitTests...PASSED
 integration: Running test com.bloomhealthco.domain.TransactionalFalseTests...PASSED
        unit: Running test com.bloomhealthco.domain.RateAreaUnitTests...PASSED
        unit: Running test com.bloomhealthco.domain.RateDependentTypeUnitTests...PASSED
 integration: Running test com.bloomhealthco.filter.EmployerFiltersTests...PASSED
        unit: Running test com.bloomhealthco.domain.RateUnitTests...PASSED
...

When it’s done, it checks the exit status code of each individual run. If any failed, the splitTests script will enumerate the ones that failed and will also return a non-zero exit status code.

The first time you run this, it will probably be slow, as each thread is compiling it’s own set of class files into it’s own “target” directory. After the initial compilation, things should be a lot quicker for the 2nd run.

If you’ve only got a couple of tests, you likely won’t see any speedup from this as the fixed grails cost for boostrapping the environment in each thread will outweigh the parallelization of tests.

If you’ve got other types of tests that you’re running, it’s easy to just add other phases into the existing threads (or create new threads for them), just by adding to the map that we spin through.

I’ll probably dig into the grails internals some more to see if some of it can be refactored to make running tests in parallel easier. The latest versions of JUnit have some support for running tests in parallel, but it isn’t easily achieved with the current grails test/environment bootstrap.

My long term goal is to create a grails script that lets the user specify a number of worker threads to be used for testing. Those workers are then fed test classes to chew on and the load would be distributed better than it is currently.

I’ve made some enhancements to them in the interim that have made them even easier to use.

The most important alias is gtaf, which is short for “grails test-app” for failed tests.

It will search through your test output directory and look for any tests that failed. If it finds any, it will rerun only those tests. Otherwise, it will rerun all tests. That makes it easy to just use gtaf all the time. If any tests fail, it will open them up using Console.app.

If you’re not on OSX, or would like to use something else to view the failed test logs, just modify the testlog alias to do something different.

There are alternative versions of it to only run failed integration tests (gtaif – Grails Test App Integration Failed), failed unit tests (gtauf – Grails Test App Unit Failed) or attach a debugger to the tests as they run (gtadf – Grails Test App Debug Failed).

These aliases, plus most of the rest of my zsh setup, is available on bitbucket. If you haven’t used zsh before and are still using bash, I suggest switching over for the numerous benefits that it gives you.

Here’s the section of zshrc_general that has the grails testing aliases, just add this to your .zshrc/.bashrc and make sure to uncomment the appropriate GRAILS_TEST_LOG_DIRECTORY export if you’re not running grails 1.2 yet:

# grails > 1.2
export GRAILS_TEST_LOG_DIRECTORY=target/test-reports
 
# grails < 1.2
# export GRAILS_TEST_LOG_DIRECTORY=test/reports
 
# after grails-test if there were ERROR messages, you can open those logs with the Console.app using this
alias testlog='for F in `grep -lE "FAILED|Caused\ an\ ERROR" $GRAILS_TEST_LOG_DIRECTORY/plain/*.txt`; do echo ">>> opening" $F; open -a Console $F; done;'
 
# grails-debug-suspend doesn't exist by default, it's a copy of grails-debug with the suspend flag changed to "y" so that
# we can attach a remote debugger before it proceeds past startup
 
# aliases where you can optionally pass in a set of tests to run (or no argument to run all tests in that group)
alias gta=grailsTestApp
alias gtad=grailsTestAppDebug
alias gtau=grailsTestAppUnit
alias gtaud=grailsTestAppUnitDebug
alias gtai=grailsTestAppIntegration
alias gtaid=grailsTestAppIntegrationDebug
 
# aliases that will rerun any failed tests (or all tests if there aren't any failed tests)
alias gtaf=grailsTestAppFailed
alias gtadf=grailsTestAppDebugFailed
alias gtauf=grailsTestAppUnitFailed
alias gtaudf=grailsTestAppUnitDebugFailed
alias gtaif=grailsTestAppIntegrationFailed
alias gtaidf=grailsTestAppIntegrationDebugFailed
 
 
function grailsTestApp() { grailsTest grails "" $1 }
function grailsTestAppFailed() { grailsFailedTests grails "" }
 
function grailsTestAppDebug() { grailsTest grails-debug-suspend "" $1 }
function grailsTestAppDebugFailed() { grailsFailedTests grails-debug-suspend "" }
 
function grailsTestAppUnit() { grailsTest grails -unit $1 }
function grailsTestAppUnitFailed() { grailsFailedTests grails -unit }
 
function grailsTestAppUnitDebug() { grailsTest grails-debug-suspend -unit $1 }
function grailsTestAppUnitDebugFailed() { grailsFailedTests grails-debug-suspend -unit }
 
function grailsTestAppIntegration() { grailsTest grails -integration $1 }
function grailsTestAppIntegrationFailed() { grailsFailedTests grails -integration }
 
function grailsTestAppIntegrationDebug() { grailsTest grails-debug-suspend -integration $1 }
function grailsTestAppIntegrationDebugFailed() { grailsFailedTests grails-debug-suspend -integration }
 
function grailsFailedTests() {
	FAILED_TESTS=''
	for F in `grep -lE "FAILED|Caused\ an\ ERROR" $GRAILS_TEST_LOG_DIRECTORY/plain/*.txt`; do
		FAILED_TESTS="$FAILED_TESTS `echo $F | sed -E 's/.*TEST-(.*)Tests.txt/\1/g'`"
	done;
	echo "failed tests: $FAILED_TESTS"
	grailsTest $1 $2 $FAILED_TESTS
}
 
function grailsTest() {
	echo "Running: $1 test-app $2 $3 || testlog "
    time $1 test-app $2 $3 || testlog
}

I believe that they’ll also work fine as-is in bash, though I haven’t tested them.

Lots of good questions from the people in attendance. Thanks to everyone for showing up.

Here’s a version of it on slideshow:

I also released a new bugfix version of build-test-data earlier today (0.2.2). Mostly fixed bugs, but there’s also a new config setting that lets you disable the plugin in specified environments (suggested by Scott Vlaminck @ refactr.

So far, the proposals in the comments look fairly clunky to me and include defining whole sets of new methods like “assertEqualsButContinue(“foo”, “foo”)”, chaning assertions together jQuery-style, or using lists to hold all of our assertions.

Wouldn’t it be a lot nicer if we could continue to use the same methods that we’re already using?

In groovy, enabling soft assertions is easy with a little closure magic.

Closures have a property called the “resolveStrategy” that determines where the code inside the closure should look to resolve method names. The default resolve strategy is OWNER_FIRST.

Closure closure = { println "foo" }
assert closure.getResolveStrategy() == Closure.OWNER_FIRST

OWNER_FIRST means that if something isn’t defined inside the closure (local scope), it should check the owner of the closure to see if it can resolve it. The owner of the closure is the declaring class or another closure that contains our closure.

Closures also have a property called the “delegate”. By default, the delegate is equal to the owner, but we have the ability to change the delegate to something else. We can also change the resolveStrategy for the closure so when something isn’t defined, the delegate is the first place that is checked.

class Original {
   def closure = { return value() }   
 
   def value = { return "value from owner" }
}
 
class SomethingElse {
    def value = { return "value from delegate" }
}
 
def obj = new Original()
 
assert "value from owner" == obj.closure()
 
// the owner is the enclosing class, and its the same as the delegate by default
assert obj.closure.owner.class == Original
assert obj.closure.owner == obj.closure.delegate
 
// but we can change the closure's delegate to something else if we want
obj.closure.delegate = new SomethingElse()
 
// by default, the closure looks at the owner before the delegate, value is unchanged
assert "value from owner" == obj.closure() 
assert obj.closure.getResolveStrategy() == Closure.OWNER_FIRST
 
// changing the closure's resolve strategy switches who gets to handle value()
obj.closure.resolveStrategy = Closure.DELEGATE_FIRST
assert "value from delegate" == obj.closure()

Groovy also has a special metaClass method called invokeMethod that allows you to manipulate any method calls that are invoked on that metaClass.

Using these two things in conjunction, we can write a small class that lets us collect JUnit assertion errors thrown by any method starting with “assert”.

class SoftAsserts {
    def oldDelegate
    def failedAssertions = []
 
    static softAsserts(closure) {
        new SoftAsserts().bundleAsserts(closure)
    }
 
    private bundleAsserts = { closure ->
        closure.resolveStrategy = Closure.DELEGATE_ONLY
        oldDelegate = closure.delegate
        closure.delegate = this
        closure()   
        if (failedAssertions) {
            throw new Exception("${failedAssertions.size()} failed assertions found:\n${failedAssertions.message.join('\n')}")
        }
    }
 
    def invokeMethod(String name, args) {
        if (name.startsWith("assert")) {
            try {
                return oldDelegate.invokeMethod(name, args)
            } catch (junit.framework.AssertionFailedError e) {
                failedAssertions << e
            }
        } else {
            return oldDelegate.invokeMethod(name, args)         
        }
    }
}

This test class does a static import of the SoftAsserts.softAsserts closure so it can use it in a natural way.

import grails.test.*
import static SoftAsserts.softAsserts
 
class BookTests extends GroovyTestCase {
    void testBookTrueAssertsPasses() {
        def book = [title: "Infinite Jest"]
 
        // all 4 assertions pass and we are able to refer to local variables 
        // like book and local methods like trueMethod() 
        softAsserts { 
            assertTrue true
            assertTrue trueMethod()
            assertNotNull book
            assertEquals "Infinite Jest", book.title
        }
    }
 
    void testBookFalseAssertsCollectsFailures() {
        def book = [title: "Infinite Jest"]
 
        // all 4 assertions throw errors, but all are collected before 
        // an exception is actually thrown
        softAsserts { 
            assertTrue "False is not true", false
            assertTrue "falseMethod() is not true", falseMethod()
            assertNull "Book is not null", book
            assertEquals "House of Leaves", book.title
        }   
    }
 
    def trueMethod() { true }   
 
    def falseMethod() { false }
}

The first test shows how a passing test can successfully refer to other variables and methods defined inside the test class. The second test fails, but it doesn’t fail till all 4 of the assertions are tried and collected. It then throws an error with the assertion failure count and the individual error messages:

Testcase: testBookFalseAssertsCollectsFailures took 0.371 sec
	Caused an ERROR
4 failed assertions found:
False is not true
falseMethod() is not true
Book is not null
expected:<[House of Leaves]> but was:<[Infinite Jest]>

It might be useful to also print out the individual stack traces for each assertion error, but this is left as an exercise for the reader.

In most situations, I like the fail fast behavior and limiting tests to exercising one feature at a time, but there have been a few test cases where something like this would’ve been nice.

The build-test-data plugin makes creating integration test data easy. It decorates your domain objects with a “build” method that will create new domain instances and will automatically populate required fields with data and save it to the database. This enables you to create more maintainable tests where the data you create is targeted specifically at the situations you’re trying to test, without having to go through all of the ceremony of creating the rest of the object graph that you don’t care about.

// creates a new Book instance with all required fields 
// (like the Author that the book belongsTo) populated
def b = Book.build()

To learn more about the basics of the build-test-data plugin, see this blog post and check out the Basic Usage and Sample Code wiki pages.

To install, just run the install-plugin grails command (this will also upgrade an existing plugin):

grails install-plugin build-test-data

The 0.2 version of the plugin includes a number of enhancements and bugfixes. Major highlights include:

• JodaTime support (along with any other persistable class with a zero argument constructor)
• much easier and more powerful config files (see the TestDataConfig wiki page for details and examples)

Additionally, the code has been cleaned up and refactored to be easier to understand.

See the Release Notes wiki page for full details.

I’d be interested to hear any further feedback on this plugin and other features that people might find useful. I’ve successfully been using it on my current project and it’s been a big help in keeping my tests clean and free from superfluous object construction code, as well as flexible in that it automatically adapts to a changing domain model.

The aliases are primarily just the first letter of the words in the command, which makes them easy to remember (and saves on typing). Some examples:

gta                   # grails test-app
gtai                  # grails test-app -integration
gtaud AuthorService   # grails-debug-suspend test-app -unit AuthorService

My testing aliases are probably my most often used grails aliases. They’re all “gta” (for grails test-app) followed by an optional “u” or “i” (to run only unit or integration).

There’s also an alternate for each of those commands with a “d” on the end for “debug”. I call a script named “grails-debug-suspend” which is simply a copy of the normal “grails-debug” command, but with the “suspend” flag set to “y”. This causes the application to stop right away till you attach a remote debugger. This is very useful for quick tests as its often the case that the code gets past where you have breakpoints set before you launch the debugger.

These commands all also let you pass in the name of a specific test class so that only that test runs.

The overall format for all of the aliases is:

gta[i|u][d] [TestClassName]

This example suspends until a debugger is attached and then runs the AuthorServiceTests.groovy unit test class:

gtaud AuthorService

These aliases are all set up to run the “testlog” alias if a failing exit code is returned from the test run. This searches through all of the testlog results for any failures and automatically opens up each failing testlog in the OSX Console.app (if you’re on another platform, just substitute a different editor). I wrote a more detailed post a while ago about how nice Console.app is for looking at grails test logs.

Lastly, each command is also run with the unix “time” command, which I find useful to help me see how long my tests are taking and get a feel over time for the overall performance of the system under test.

# grails-debug-suspend doesn't exist by default, it's a copy of grails-debug with the suspend flag changed to "y" so that
# we can attach a remote debugger before it proceeds past startup
 
alias gta=grailsTestApp
function grailsTestApp() { grailsTest grails "" $1 }
 
alias gtad=grailsTestAppDebug
function grailsTestAppDebug() { grailsTest grails-debug-suspend "" $1 }
 
alias gtau=grailsTestAppUnit
function grailsTestAppUnit() { grailsTest grails -unit $1 }
 
alias gtaud=grailsTestAppUnitDebug
function grailsTestAppUnitDebug() { grailsTest grails-debug-suspend -unit $1 }
 
alias gtai=grailsTestAppIntegration
function grailsTestAppIntegration() { grailsTest grails -integration $1 }
 
alias gtaid=grailsTestAppIntegrationDebug
function grailsTestAppIntegrationDebug() { grailsTest grails-debug-suspend -integration $1 }
 
function grailsTest() {
	echo "Running: $1 test-app $2 $3 || testlog "
    time $1 test-app $2 $3 || testlog
}
 
# after grails test if there were ERROR messages, you can open those logs with the Console.app using this
alias testlog='for F in `grep -lE "FAILED|Caused\ an\ ERROR" test/reports/plain/*.txt`; do echo ">>> opening" $F; open -a Console $F; done;'

You can place these aliases in your .bashrc/.bash_profile in your home directory (you can also use them with cygwin on windows.

Alternatively, if you’re using zsh (or interested in switching from bash), I’ve got all of my zsh setup shared in a source control repo in a format that’s easy to use and extend for yourself.

This is the modified grails-debug command called grails-debug-suspend, just put it somewhere in your PATH and make it executable (chmod +x grails-debug-suspend):

#!/bin/bash
 
DIRNAME=$GRAILS_HOME/bin
. "$DIRNAME/startGrails"
 
JAVA_OPTS="$JAVA_OPTS -Xdebug -Xnoagent -Dgrails.full.stacktrace=true -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005"
startGrails org.codehaus.groovy.grails.cli.GrailsScriptRunner "$@"

Often an entire object graph needs to be created to support the instantiation of a single domain object. This leads to either the cutting and pasting of that creation code, or relying on a canned set of objects that we’ve grown over time and maintained as the domain objects change. After a while, adding just one more Widget to that set of canned data ends up breaking tests just about every time.

There has to be a better solution, right?

Yep! Due to the “Power and the Glory of Grails”™, we have a lot of metadata at our fingertips about those domain objects. We know what validation constraints we’ve placed on our objects, and which objects depend on other objects to live.

Using this additional information, Joe Hoover and I have created a grails plugin called “build-test-data”. With it, you can create test data and omit the fields that you don’t care about for your test. The plugin takes care of populating the values required by constraints and persists your domain objects to the database.

This plugin is focused on creating test data for integration testing. If you’re doing unit testing, there are a number of mocking solutions out there (including a few ways to do it built right into groovy). Unit testing only goes so far though, and if you want to ensure that your code works when it’s hooked up to a real database, with real transactions, saving, triggers, etc, you’re only going to get that from an integration test.

Installation of the plugin is easy. Just run this grails task in the root of your project:

grails install-plugin build-test-data

When the plugin is installed, most domain object should be able to be instantiated and persisted out of the box.

// automatically creates/saves a Book with all required fields populated
def book = Book.build()

Once installed, all you have to do is call the new build() method on your domain class and you’ll be given a valid instance that has been persisted to the database.

It will populate the required fields as defined by the constraints and it has the ability to deal with almost all of them.

A couple of them, such as custom validations and regular expressions, are very difficult to work with so if a sample value that we try doesn’t get past validation, we’ll throw an error.

Build Test Data Example

Here’s a quick example. Say you have the following domain objects:

// grails-app/domain/Author.groovy
class Author {
    String firstName
    String lastName
    static hasMany = [books: Book]    
}
 
// grails-app/domain/Book.groovy
class Book {
    String title
    Date published
    BigDecimal price
    static belongsTo = [author: Author]    
}

Remember that grails properties are required unless nullable is explicitly set to false, so all of those properties are required.

If you’re testing a BookPurchasingService and the method you’re calling needs a Book, normally you’d need to also create an Author to go with it. Here’s how you might normally create your test data without the build-test-data plugin:

void testPurchaseBookService() {
	def author = new Author(firstName: "first", lastName: "last")
	author.save()
	Book tenDollarBook = new Book(author: author, title: "title", published: new Date(), price: 10.00 as BigDecimal)
	tenDollarBook.save()
 
	def result = service.purchaseBook(tenDollarBook)
 
	//... assertions about expected result of service call
}

You need to create an Author just to create the Book, even though your service only cares about the Book. If the Author class ever adds an additional required field, you not only need to update all of your Author test classes, but all of your Book test classes as well.

Additionally, there’s all kinds of “noise” in your test class that makes it more difficult to understand exactly what it is you’re trying to test.

If you’ve got the build-test-data plugin installed, you don’t need to worry about any of that. Creating sample data is easy and you can specify only the parameters that you actually need specific values in to exercise your test. The plugin will fill in the rest and persist it to the database automatically.

void testPurchaseBookService() {
	def result = service.purchaseBook( Book.build(price: 10.00 as BigDecimal) )
 
	//... assertions about expected result of service call
}

Behind the scenes, build-test-data populates the Book.title and Book.purchased fields, it also creates a new Author with a firstName and lastName and saves all of that to the database.

This test is much cleaner as you only see the things that actually matter to the test and none of the administrative flotsam and jetsam needed to set things up.

In the repository on the bitbucket website, there is a test “bookstore” grails application that has a fairly complex domain model that exercises the build-test-data build method and it’s ability to serialize an object graph.

Check out the full set of documentation on the bitbucket build-test-data wiki and let Joe and I know what you think of it.