Mar 3, 2015

Customize your Grails test reports

I’ve been writing a lot of Spock tests, and I discovered that Grails’ power asserts can be a little confusing when you’re dealing with long string representations. For example, given the simple test code:

the test output on failure looked all muddled.

On most widescreen monitors, it would be helpful to increase the width of those containers to at least help alleviate the problem. So I looked into altering the test report generation and output, and found that it was actually pretty easy.

Step 1 – Copy the XSL Files

The first step is to find the xsl files being used to generate the reports (which is done in JUnitReportProcessor.groovy) and copy them to the directory where you want your new report templates to live. Now, I suppose you can skip this step if you want to start from scratch, but I am not nearly that adventurous.

Note that as of GRAILS-7320 the JUnitProcessor will look in the subdirectory /saxon if the initial fetch throws an exception. So if that issue applies to you, you will need to create that directory under your target one. It doesn’t seem like Grails uses a junit-noframes.xsl, but it’s present in the project in case you want to copy it too.

I believe the xsl hasn’t changed for some time, but you may want to find the one specific for your version just in case. I used this one from GitHub.

Step 2 – Create a new config property

If you intend on your changes being used by other developers (and maybe even if you don’t), it’s a good idea to create a new Config property to allow each environment to customize the location of these new templates. The setting can reside in an external config, so that each user can make changes to the template without affecting anyone else. If you don’t need this level of customization (like if the template will live in the same source control repo as the tests) then this isn’t as big of a deal.

So let’s go ahead and add to the Config:

Remember that if you created a “saxon” subdirectory, you do NOT need to include in the path above, as Grails will automatically grab it for you if it can’t find junit-frames.xsl directly.

Step 3 – Tell Grails to use our new path

As of GRAILS-5617, Grails lets us configure the test report template location, so let’s edit _Events.groovy to use our new property.

The code above will use the config if the property exists, otherwise it will set the junitReportStyleDir to null, meaning Grails will use the default location. This is also useful if you need environment-specific reports.

Step 4 – Make your changes!

Finally, open up the new xsl template you copied, and modify it as needed. I had made some minor CSS tweaks to increase the width for my monitor, but you can certainly make more complex changes. Bear in mind that you will need to re-run the tests after making a change to the template. If you get an error about the file not being found, be sure you have properly specified the Config property and its location value. I tested these changes in Grails 2.2, but I believe they should work at least for versions 1.3 through 2.3 as well.

In my case the output was much improved.

Igor Shults

About the Author

Object Partners profile.
Leave a Reply

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

Related Blog Posts
Android Development for iOS Developers
Android development has greatly improved since the early days. Maybe you tried it out when Android development was done in Eclipse, emulators were slow and buggy, and Java was the required language. Things have changed […]
Add a custom object to your Liquibase diff
Adding a custom object to your liquibase diff is a pretty simple two step process. Create an implementation of DatabaseObject Create an implementation of SnapshotGenerator In my case I wanted to add tracking of Stored […]
Keeping Secrets Out of Terraform State
There are many instances where you will want to create resources via Terraform with secrets that you just don’t want anyone to see. These could be IAM credentials, certificates, RDS DB credentials, etc. One problem […]
Validating Terraform Plans using Open Policy Agent
When developing infrastructure as code using terraform, it can be difficult to test and validate changes without executing the code against a real environment. The feedback loop between writing a line of code and understanding […]