I just migrated a grails 2.2 app to grails 2.3. Of course I didn’t read the doc in advance — I (almost) never do. Rather than read the doc, I created a project with the old version of grails and another project for grails 2.3. A directory diff of the two shows where the changes are. With grails 2.3 the biggest changes are in
Config.groovy. That’s not too surprising and it’s pretty easy to clean up the changes and migrate the files in my existing app. After that the app compiled but many of the tests failed: I uncovered a few problems while trying to unwind it all. Here are the highlights…
Jumping back and forth between testing the app in the interactive mode and from a single command `grails test-app` is not too smooth. At one point I ended up with a forked jvm process that just kept on running and wouldn’t die until I killed the shell. Not sure how I got into that state, but IMHO running tests “faster” is never worth having to worry about zombie processes/forks that may or may not auto-reload changes. And killing the process by itself wasn’t enough of a kick in the a** to grails to set things right. I hope it’s better in 2.3.1.
The good news: if you struggle with forked JVMs it’s easy to disable in
grails.project.fork = [ test: false, run: [maxMemory: 768, minMemory: 64, debug: false, maxPerm: 256], war: [maxMemory: 768, minMemory: 64, debug: false, maxPerm: 256], console: [maxMemory: 768, minMemory: 64, debug: false, maxPerm: 256], ]
One of the best features of grails is the auto reload of classes when running the app. But in grails 2.3 auto-reloading is NOT ENABLED by default. WTF? If you want auto reload changes you’ve got to add the
-reloading flag to the command…
grails -reloading run-app
This includes running grails in interactive mode. If you don’t start up with
-reloading the interactive mode won’t pick up any class changes. Don’t know why they made this change (maybe something to do with the forked daemon processes?)
You can also turn on loading by default in
grails.reload.enabled = true
Not only is spock included as part of grails, it is also the default test runner. This is great news and if you weren’t already using spock now’s the time to switch (Why Spock?.)
Simply migrating a 2.2.2 grails application that already used the spock plugin to 2.3 will end up double running the spec tests. Here’s console output for running a single test class with one test method…
> grails test-app unit: DomainTestUtilSpec | Completed 1 unit test, 0 failed in 0m 0s | Running 1 spock test... 1 of 1 --Output from stringWithLength-- | Error --Output from stringWithLength-- | Completed 1 spock test, 0 failed in 0m 0s | Tests PASSED - view reports in [snip]/target/test-reports >
The solution is to remove all spock references from
BuildConfig.groovy. If you don’t, tests will be run twice. Why? Spock is now included as a built in test runner as part of grails 2.3. If you migrate an app and leave the spock plugin then the default spock test runner will run the test, and then the plugin will too.
Maybe that’s not so bad but it sure would be nice to get some sort of warning about no longer needing the spock plugin in
In grails 2.2.x spock (*Spec) tests extended
grails.plugin.spock.IntegrationSpec but with spock’s inclusion as part of grails that class is no longer present. In 2.3 simply extend
spock.lang.Specification (just like a unit test.)
"The default behavior is such that a blank string will not validate for nullable: false since the data binder will convert blank strings to null. This includes empty strings and blank strings."
Kind of a big change from 2.2! You can configure this behavior in Config.groovy with
But I choose to change the domain objects constraints and refactor the tests to match.
Once over the hump its time to incorporate all the new features available in grails 2.3: grails.org/doc/…whatsNew23.