Grails build-test-data plugin version 0.2.3 released

2009/08/25

I’ve just released the latest version of the grails build-test-data plugin. This version has a couple of bugfixes that were reported by users. Including one with a nice patch including a test from Robert Fletcher (patches with tests are always appreciated).

For those that aren’t familiar with the plugin, it make creating testing data easy.

It automatically adapts to changes in your domain classes and makes your integration tests easier to write and much less fragile.

Resources

Overall, the plugin has been very stable for the past few releases and I’m thinking about just bumping the version up to 1.0 fairly soon. The plugin seems pretty feature complete when balanced with it’s ease of use. Most of the other features I’ve thought of would explode the complexity level of the plugin and defeat it’s purpose. Might be best to leave well enough alone for now :).

I had a hell of a time with the current grails release-plugin cycle (6 attempts before it finally went through). The grails release-plugin command uses an old version of svnkit that’s only compatible with svn 1.5. I’ve long since upgraded to 1.6 on my mac, though luckily I did it through macports and still had the old version available to activate (sudo port deactivate subversion && sudo port activate subversion @1.5.6_0).

I did some searching around to find out how to install an old version of subversion, but didn’t come up with anything after a quick google so I might be screwed after my wipe/reinstall for snow leopard next week till Grails patches things with svnkit 1.3.

I did open up a JIRA ticket for grails to upgrade to svnkit 1.3, and I was surprised that there wasn’t already a ticket open on it (and that trunk still had svnkit 1.2 in it).

There are 4 comments in this article:

2009/08/26Rob Fletcher say:

WRT The SVN issue: In Grails 1.2-SNAPSHOT the release-plugin command accepts a -zipOnly flag that will only upload the plugin zip file to plugins.grails.org leaving you free to host the code elsewhere (bitbucket, github, etc). That might save you some pain.

Thanks again for a fantastic plugin. With this patch applied we can build useful instances of almost all our domain objects with a parameterless build() call which should prove a huge productivity gain when writing integration tests and fixtures for selenium.
2009/08/26tednaleid say:

Thanks for the tip about zipOnly. I missed that previously and that’ll be a big help to not have to do the double bookkeeping of mercurial then actually screwing around with SVN just to release the plugin.

I’m glad you guys are getting use out of build-test-data, thanks again for the patch.
2009/09/30Lucas say:

Why the grails build-test-data plugin isn’t aware of the unique constraint?
2009/09/30tednaleid say:

@Lucas, it’s aware of the unique constraint, and it would be possible to program it to fill in a value for it. I just haven’t done it mostly because I don’t use more than a couple of unique constraints in my applications (username, a few others) and just sticking a generator closure in the TestDataConfig.groovy is pretty easy and is more flexible (see the section on the wiki about “Generating Dynamic Values”).

If there’s enough demand for attempting to do this automatically, I can look further at implementing it. If the TestDataConfig.groovy doesn’t meet your needs, feel free to raise an enhancement issue (or even submit a patch :).

Ted Naleid