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 = [
  ‘org.example.*’,
  ‘org.example.**.*’,
  ‘MyService’,
  ‘MyService.testSomeMethod’
]

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.

Related Blog Posts
Natively Compiled Java on Google App Engine
Google App Engine is a platform-as-a-service product that is marketed as a way to get your applications into the cloud without necessarily knowing all of the infrastructure bits and pieces to do so. Google App […]
Building Better Data Visualization Experiences: Part 2 of 2
If you don't have a Ph.D. in data science, the raw data might be difficult to comprehend. This is where data visualization comes in.
Unleashing Feature Flags onto Kafka Consumers
Feature flags are a tool to strategically enable or disable functionality at runtime. They are often used to drive different user experiences but can also be useful in real-time data systems. In this post, we’ll […]
A security model for developers
Software security is more important than ever, but developing secure applications is more confusing than ever. TLS, mTLS, RBAC, SAML, OAUTH, OWASP, GDPR, SASL, RSA, JWT, cookie, attack vector, DDoS, firewall, VPN, security groups, exploit, […]