Peter Ledbrook has “sneakily’ released versions 0.2 and 0.3 of the Grails Testing plugin. You probably have heard about this plugin on the Grails podcast, it promises to make your testing chores a lot easier. The following are excerpts from the announcement made at the grails-user list

Version 0.2

I have released version 0.2 of the testing plugin. This doesn’t
contain either the tag lib stuff or the URL mapping test classes, but
it does include:

  • A bunch of bug fixes
  • getAll() static method for domain classes
  • More render() implementations for controllers
  • Support for mocking command objects
  • Added constructor and “.properties” based data binding
  • “.errors” on domain classes and command objects is a real “Errors” instance
  • save() method calls validate() and adds the new domain instance to
  • the list of test instances
  • “.session” is now an implementation of HttpSession, not a map

svn HEAD contains support for “withFormat” in controllers and it has
basic support for testing tag libraries. Not well tested yet though.
Now all I need is some time to document this stuff.

Version 0.3

Quickly following on, there is now a 0.3 release :)

  • Fixes a bug in ControllerUnitTestCase
  • Supports “withFormat” in controllers
  • Basic support for testing tag libraries, through the new TagLibUnitTestCase

The TagLibUnitTestCase adds an “out”property to the tag, which you can
access and call toString() on to get the content written to the output
writer. It also has support for the render tag - simply check the
“renderArgs” property to find out whether it was called with the right
arguments.

Just thought, if you call “render” more than once in a tag, this won’t
work. For other tags, you will need to do something like:

def tagLibControl = mockFor(MyTagLib)
tagLibControl.demand.link(1..1) { … }

def tagLib = new MyTagLib()
tagLib.myTag([:])

In other words, you’ll have to mock the tag method calls. It supports
the “g.” prefix, but not custom namespaces yet. Any ideas welcome.

Last minute update

Sorry, in the haste to get 0.2 and 0.3 out I think I missed mentioning
a significant change. The validate() method does return a boolean now,
just as it does “in the wild”, i.e. when used in a running
application. You need to access the errors object as you would in
normal code:

def cds2 = new CustomerDataset()
cds2.name = ”
cds2.validate()
assertEquals 1, cds2.errors.errorCount
assertEquals “blank”, cds2.errors[”name”]

The “errors” object on the domain instance is now a proper Spring
Errors instance, but we have overridden property access so that you
can still use notation like “cds2.errors[”name”]” and
“cds2.errors.name”.

You can download the plugin directly from the svn trunk.

Tags: , ,



Leave a Comment