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.

Related Blog Posts
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, […]
Building Better Data Visualization Experiences: Part 1 of 2
Through direct experience with data scientists, business analysts, lab technicians, as well as other UX professionals, I have found that we need a better understanding of the people who will be using our data visualization products in order to build them. Creating a product utilizing data with the goal of providing insight is fundamentally different from a typical user-centric web experience, although traditional UX process methods can help.
Kafka Schema Evolution With Java Spring Boot and Protobuf
In this blog I will be demonstrating Kafka schema evolution with Java, Spring Boot and Protobuf.  This app is for tutorial purposes, so there will be instances where a refactor could happen. I tried to […]
Redis Bitmaps: Storing state in small places
Redis is a popular open source in-memory data store that supports all kinds of abstract data structures. In this post and in an accompanying example Java project, I am going to explore two great use […]