Automate Grails App Tests with TeamCity - Part 2
Join the DZone community and get the full member experience.
Join For FreeAs I showed in my previous post, TeamCity can build Grails applications for you, while you keep coding, relax or sleep. We talked about the command-line runner, which executes Grails commands through the command line interface. Today I'm going to show you how to configure the Ant runner, which gives us more flexibility and allows us to integrate test reports into TeamCity UI.
Different projects and teams have different needs regarding continuous integration, but some requirements are likely to be more frequent than the others. I usually configure TeamCity to perform the following tasks for me:
- Compile and run unit tests for pre-tested commit (before my changes hit the VCS) to avoid simple errors from breaking the build
- Run a complete set of tests after each commit
- Run a complete set of all unit and integration tests with code-coverage calculation enabled periodically every night
- Run webtests periodically every night
- Generate war file for the test server if all automated webtests have finished successfully
Enable unit and integration tests
I'll show you now, how to configure your project in TeamCity to run unit tests before each commit and a complete Grails test suite after commit.Modify the build.xml file
The Ant runner may use the build.xml file in the root of the Grails app and invoke required targets from it. So we need to add required targets into the build.xml file. Of course, you may create a completely separate Ant build file not to mess up with the default build.xml file and point TeamCity to the new file.
<!-- =================================
target: test
================================= -->
<target name="unittest" description="--> Run a Grails applications unit tests">
<exec executable="${grails}" failonerror="false" resultproperty="resultCode">
<arg value="test-app"/>
<arg value="-unit"/>
</exec>
<zip basedir="test/reports/html" destfile="test/reports/unitTestReport.zip"/>
<fail status="1" message="Some unit tests failed">
<condition>
<equals arg1="${resultCode}" arg2="1"/>
</condition>
</fail>
</target>
<!-- =================================
target: test
================================= -->
<target name="test" description="--> Run a Grails applications unit and integration tests">
<exec executable="${grails}" failonerror="false" resultproperty="resultCode">
<arg value="test-app"/>
</exec>
<zip basedir="test/reports/html" destfile="test/reports/testReport.zip"/>
<fail status="1" message="Some tests failed">
<condition>
<equals arg1="${resultCode}" arg2="1"/>
</condition>
</fail>
</target>
We added two targets, they both look very similar, the only difference is in the arguments for the grails command. After the grails command finishes running tests, the return code is stored in the resultCode property and the generated test report is zipped into a zip file. Based on the values stored in the resultCode property we either succeed or fail the whole build. Please notice the failonerror attribute being set to false to ensure the testreport is generated even when some tests failed.
Modify artifact mapping
TeamCity keeps a list of test report file names, so that the reports can be browsed on-line inside TeamCity UI. The mappings are stored in the .BuildServer/config/main-config.xml file. We need to add the two following lines to the file to indicate that the two zip files, which we created in our Ant build script, contain reports.
<report-tab title="Unit Tests" basepath="unitTestReport.zip" startpage="index.html" />
<report-tab title="Grails Tests" basepath="testReport.zip" startpage="index.html" />
[img_assist|nid=803|title=|desc=|link=none|align=left|width=428|height=232]
This settings ensures that we can open the report directly from TeamCity and view it on-line.
[img_assist|nid=807|title=|desc=|link=none|align=left|width=640|height=274]
Configure Ant runner
The last step is to configure the Ant runner for our configuration to execute the appropriate Ant target. It is very straightforward as shown in the picture.
[img_assist|nid=1031|title=|desc=|link=none|align=left|width=640|height=398]
On top of the build file and the target to invoke a path to the report zip file must be specified so that TeamCity saves it for browsing. Thanks to the mapping in .BuildServer/config/main-config.xml file TeamCity knows that the file contains a report and will offer it for on-line viewing.
That's all for today. Next time I'll show you how to extend our tests to generate code-coverage data for your Grails applications and how to visualize them in TeamCity.
Opinions expressed by DZone contributors are their own.
Trending
-
Enriching Kafka Applications With Contextual Data
-
PostgreSQL JSONB Cheatsheet: Complete and Fast Lookup Guide
-
The Internet of Java: Eclipse's Open IoT Stack for Java
-
Low Code vs. Traditional Development: A Comprehensive Comparison
Comments