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. Required fields are marked *

Related Blog Posts
AWS Cloud HSM, Docker and NGINX
There is quite a bit of easily searchable content on the security benefits of leveraging a Hardware Security Module to manage cryptographic keys, so I will leave that to the scope of another article. The […]
Google Professional Machine Learning Engineer Exam 2021
Exam Description A Professional Machine Learning Engineer designs, builds, and productionizes ML models to solve business challenges using Google Cloud technologies and knowledge of proven ML models and techniques. The ML Engineer is proficient in all aspects […]
Designing Kubernetes Controllers
There has been some excellent online discussion lately around Kubernetes controllers, highlighted by an excellent Speakerdeck presentation assembled by Tim Hockin. What I’d like to do in this post is explore some of the implications […]
React Server Components
The React Team recently announced new work they are doing on React Server Components, a new way of rendering React components. The goal is to create smaller bundle sizes, speed up render time, and prevent […]