So I’ve started writing tests a little differently and have been trying to reduce the number of times setUp() and tearDown() are called within a test class.  This is probably a good practice, regardless of the unit testing mechanism you’re using. Here’s an example – I used to have really verbose test methods, like this:

testFirstNameBlankConstraint(){...}
testFirstNameNullableConstraint(){...}
testFirstNameMaxSizeConstraint(){...}
testFirstNameValid(){...}

I like this pattern because each test method tested one thing – so if the test method failed, it was pretty obvious what went wrong.

However, setUp and tearDown methods were being called for each of these test methods which added some extra time to run the test suite. In a relatively small project, the time is so negligible it doesn’t matter. But on a large project with thousands of tests, it can be a noticeable difference.

Now when I’m writing my tests, I set ‘em up more like this:

testFirstNameConstraint() {
    // some test code
    assertEquals ("blank constraint", ..., ...)
 
    // some test code
    assertEquals ("null constraint", ..., ...)
 
    // some test code
    assertEquals ("max size constraint", ..., ...)
 
    // some test code
    assertEquals ("valid", ..., ...)
}

In this example, the same testing is occurring, but I have only one test method instead of four (three less calls to setUp and tearDown). By passing a message as the first parameter to the assertions, I can still quickly determine which assertion failed, and my test suite runs more quickly.

class Book {
	String title
	String subTitle
	Date publishedDate
	static constraints = {
		title(nullable:false, blank:false, size:1..100)
		publishedDate(nullable:true)
	}	
}

With the plugin installed, type “grails generate-domain-unit-test Book”

The plugin will generate and stub out a unit test for you in test/unit/BookUnitTests.groovy. It’s not completely magic – you still need to do some work now:

• in the setup method, fill in all the properties that would make your domain class validate
• in each test method, write test code that will test your constraints. The plugin provides comments indicating which constraints are applied to a given property, you just need to write the test code.

Here’s what a stubbed unit test looks like out of the box:

import grails.test.GrailsUnitTestCase
class BookUnitTests extends GrailsUnitTestCase {
    Book book 
    void setUp() {
        super.setUp()
        // in testing-plugin 0.4 you can just do "mockForConstraintsTests(Book)" instead of these two lines
        registerMetaClass(Book) 
        grails.test.MockUtils.prepareForConstraintsTests(Book)
	// TODO - fill out this book instance so it validates
	book = new Book()
        assertTrue "setup method: book should validate", 
			book.validate()
        }
	void testTitleConstriants() {		 
		//test org.codehaus.groovy.grails.validation.NullableConstraint@de1237[false]  
		//test org.codehaus.groovy.grails.validation.BlankConstraint@7bc5fd[false]  
		//test org.codehaus.groovy.grails.validation.SizeConstraint@36f09[1..100] 
	}	
	void testPublishedDateConstriants() {		
		//test org.codehaus.groovy.grails.validation.NullableConstraint@6ec9d4[true] 
	}	
	void testSubTitleConstriants() {		
		//test org.codehaus.groovy.grails.validation.NullableConstraint@849937[false] 
	}	
}

This is helpful in reminding you what you actually need to test – for example, did you remember that by not defining a constraint for the ’subTitle’ property, grails makes it a non-nullable field?

By the way, the script also works with the uber generate feature of Grails 1.0.4 – so if you have lots of domain classes and want to generate unit tests for all of them in one fell swoop, you can type:

grails generate-domain-unit-test "*"

and it will stub out unit tests for all your domain classes.

I’m thinking future versions of the plugin could go even further by offering:

• A ‘verbose’ template that would create multiple test methods for each possible test scenario for a given constraint, for instance a ’size:5..100′ constraint could generate test methods for:
• a string with a size of 4 (e.g. less than the minimum)
• a string with a size of 101 (e.g. more than the maximum)
• a string with a size of 50 (e.g. within the bounds of the constraint)
• Actually write the test code. Not sure if I’m totally warmed up to this idea yet, but it may be worth looking into. Contributions welcome, of course

Give it a shot. You can install the plugin by running the following commands:

grails install-plugin testing
grails install-plugin test-template

I’ve always thought a good addition to Grails would be the ability to generate unit tests for all that scaffolding code in your generated controllers. With the advent of testing enhancements coming to Grails 1.1 and the Grails Testing Plugin making it much easier to unit test Grails artifacts, this is more of a reality.

So I buckled down and created a plugin with a template for testing generated controllers. If you’re on Grails 1.0.4, it hooks directly into events in the build system to create the unit test file automagically. If you haven’t upgraded yet and you’re still on Grails 1.0.3, there’s a script you can call to generate the unit test manually.

I decided to make the Testing Plugin a pre-requisite for the “Test Template” plugin, since it makes the test code SO much easier to write. So to get started, run “grails install-plugin testing“, followed by “grails install-plugin test-template“. Here’s an small example:

grails create-app bookstore
cd bookstore
grails install-plugin testing
grails install-plugin test-template
grails create-domain-class Book
grails generate-controller Book (or you could run generate-all Book)

If you have Grails 1.0.4, that last line will generate the controller for you AND also generate a unit test (test/unit/BookControllerUnitTests.groovy). The unit test will have test methods for each controller action, with several test methods for each of the actions that have if/else statements in them.

If you have Grails 1.0.3, you have to manually generate the unit test, which you can do with this line:

grails generate-controller-unit-test Book

Yes, that’s a long command name, but what are you doing still on Grails 1.0.3 anyway? Grails 1.0.4 has been out for like 48 hours – go upgrade already!

Now run your test suite (grails test-app) and watch your newly generated tests scroll by!

The plugin uses the createArtefact method in Init.groovy, so it also handles packages:

grails create-domain-class com.pirgaua.Book
grails generate-controller com.piragua.Book
// -> generates test/unit/com/piragua/BookControllerUnitTests.groovy

And, it also handles the new “uber-generate” feature in 1.0.4 (courtesy of Marcel Overdijk and GRAILS-2946:

grails create-domain-class Book
grails create-domain-class Author
grails create-domain-class Store
grails create-domain-class Cart
// edit your domain classes and add properties, constraints, etc...
grails generate-all "*"
// -> generates controllers, views, and controller unit tests for ALL your domain classes

And you can override the plugin provided template, just run “grails install-test-templates” and modify the template code to suit your own needs (the templates are copied to src/templates/artifacts/test-templates).

Speaking of the next version – the next feature I want to add to the plugin is a way to generate a unit test for testing domain constraints. Stay tuned!

More documentation on the Test Template plugin page at grails.org

TADA! Now the reports are showing the coverage I expect. I know Cobertura (version 1.9) improved on the way it calculates branch coverage (see the news item from 5 June 2007 on the Cobertura website) but for my purposes, Cobertura 1.8 gives me more of the information that I need. I’m mostly concerned with finding code that isn’t tested at all, and that’s hard to do when almost every line of code is highlighted in red like version 1.9 was doing:

So for now I’ve updated the Grails code-coverage plugin to utilize Cobertura 1.8. I can live without the new features that 1.9 offers and in the meantime I’ll work with the cobertura-devel folks to see if there’s something that we can improve for a future release.