Set up a pseudo test suite in Grails while doing a major upgrade

I’m currently working with a large team to upgrade a large Grails 1.3.7 app to 2.2.4. We have  hundreds of tests. Most of the tests are broken, presumably because they have yet to be adapted to the new ways of doing things. Running the entire test suite is not beneficial because it results in a blizzard of errors. So, a developer will typically fix an area of the app and only the related test classes. That is, they will usually run only the tests relevant to the area of the application they are fixing, rather than running the whole suite, before committing their changes. The problem with this is that they often have no idea if their changes have broken something else that’s already been ‘fixed’ for Grails 2.2.4.

One way to help with this is to maintain a list of tests have have been fixed, and then continually run only those tests. But where would we keep this list, and how would we inform the test runner that we only want to run the tests from this list? Digging into the source for the _GrailsTest.groovy script provides one clue. You’ll notice that the script looks for the following config option: “buildConfig.grails.testing.patterns”, and there are some helpful comments that show how to set that option. It wasn’t immediately clear (to me) what the syntactical rules are for setting this option. It took a little bit of experimenting before I figured out that it should just be a regular Groovy list of Strings. To use this option, simply add the following to your BuildConfig.groovy file:

grails.testing.patterns = [

Again, it needs to be a list of Strings where each value is a valid pattern option you might pass to the “test-app” command-line argument. With this option set, the test runner will only run the tests that match your list of strings. This is very handy when you need to fix a large set of tests one-by-one, and you want to make sure you don’t regress. As you fix a test, just add it to the list.

If one of these tests fail, you know it’s something to pay attention to (rather than just another of the many that might fail just because they haven’t been updated yet). This does not impact your ability to use the test-app script in other ways (for example, to run only unit tests, integration tests, etc…). It simply overrides the default pattern of “**.*”.

Once all the tests have been fixed, you can remove this option and go back to using the default pattern.

Note that this technique will work with Grails 2.3 as well.

About the Author

Object Partners profile.
Leave a Reply

Your email address will not be published. Required fields are marked *

Related Blog Posts
Using Conftest to Validate Configuration Files
Conftest is a utility within the Open Policy Agent ecosystem that helps simplify writing validation tests against configuration files. In a previous blog post, I wrote about using the Open Policy Agent utility directly to […]
SwiftGen with Image & Color Asset Catalogs
You might remember back in 2015 when iOS 9 was introduced, and we were finally given a way to manage all of our assets in one place with Asset Catalogs. A few years later, support […]
Tracking Original URL Through Authentication
If you read my other post about refreshing AWS tokens, then you probably have a use case for keeping track of the original requested resource while the user goes through authentication so you can route […]
Using Spring Beans in a Kafka Streams ExceptionHandler
There are many things to know before diving into Kafka Streams. If you haven’t already, check out these 5 things as a starting point. Bullet 2 mentions designing for exceptions. Ironically, this seems to be […]