Skip to content
This repository

Provides a way to execute Grails integration tests automatically when tests or artifacts change. This is very similar to the Rails plugin of the same name and a distant cousin of Spork.

branch: master

Fetching latest commit…

Octocat-spinner-32-eaf2f5

Cannot retrieve the latest commit at this time

Octocat-spinner-32 .settings
Octocat-spinner-32 grails-guard
Octocat-spinner-32 testapp
Octocat-spinner-32 .gitignore
Octocat-spinner-32 README.md
Octocat-spinner-32 build.gradle
Octocat-spinner-32 ideaCodeStyle.xml
Octocat-spinner-32 ideaSpring.xml
Octocat-spinner-32 settings.gradle
README.md

Grails Guard

Guard provides a convenient way to run integration tests without having to suffer repetitive startup costs. Each time an integration test suite runs, the grails environment must be compiled and bootstrapped. For a large application, especially one with many domain objects, this can take over a minute just to run a single testcase. Over the course of several months this can lead to days of lost productivity just waiting for tests to run.

This plugin borrows from the similarly named Rails plugin (although it is more targeted at just running tests in this incarnation).

The plugin essentially runs the tests in a loop, detecting changes to both the application code and the test code. If a change is detected, the selected test(s) are re-run.

Versions

Due to major changes in the test framework introduced in Grails 2.3, Guard now comes in two different versions:

  • Version 1 - Compatible with Grails 2.0, 2.1, or 2.2
  • Version 2 - Compatible with Grails 2.3 or later.

Usage (Version 2)

Starting with version 2, Guard is no longer implemented as a test phase. Guard is now enabled via the command line flag "-guard".

There are a few advantages to this approach. From an implementation standpoint, this allows Guard to fit more seamlessly into the new 2.3 test framework. It will also (eventually) allow Guard to support functional tests in addition to integration tests.

To run your tests in guard mode, you need to do a few things:

  1. Enable the spring reloading agent by adding the "-reloading" flag to the command line
  2. Disable forked mode execution for 'test' in BuildConfig.groovy
  3. Enable guard by adding the "-guard" flag to the command line when running integration test(s)

For example:

grails -reloading -guard test-app integration: <testpatterns...>
grails -reloading -guard test-app integration: MyService

If you want to see the console output, use:

grails -reloading -echoOut -guard test-app integration: <testpatterns...>

Finally, to make life easier, just create an alias in your .bashrc:

alias guard='grails -reloading -echoOut -guard test-app integration:'

Then run:

guard my.package.*
guard MyService
guard MyService MyOtherService

This will run the tests once as it normally would. Regardless of the success or failure of the tests, it will then enter a mode where it detects changes to application code and test code. When a change is detected, it will indicate which file was changed and then run the same test pattern again with the updates.

Usage (Version 1)

For version 1, Guard is still implemented as a test phase replacement for "integration:".

To run your tests in guard mode, you need to do a few things:

  1. Enable the spring reloading agent by adding the "-reloading" flag to the command line
  2. Enable guard by specifying the "guard:" test phase after 'test-app'

For example:

grails -reloading test-app guard: <testpatterns...>
grails -reloading test-app guard: MyService

Finally, to make life easier, just create an alias in your .bashrc:

alias guard='grails -reloading -echoOut test-app guard:'

Then run:

guard my.package.*
guard MyService
guard MyService MyOtherService

IDE Support

IntelliJ (and possibly Eclipse though I haven't tried it) can also be used to run guard mode.

In IntelliJ, run an integration test once normally. This will give you a "configuration" for the test case which can be edited. Click to edit the profile and add the -guard flag. You may also need to add the "-reloading" flag to the end of the command line.

When you run that configuration, IntelliJ will process the tests normally and then "spin" as if it's waiting for more tests. As you modify files, you will see the same tests run again. Since guard never notifies the listeners that the test run is complete, IntelliJ will continue waiting for tests until you stop it manually.

Known Issues

  • Since the environment is not reloaded, tests must be careful to cleanup after themselves, even if running against the in-memory database since the create-drop only happens when the environment is bootstrapped.
  • Depending on the classes being changed, you may encounter PermGem issues if Guard loops for an extending number of iterations.
  • If you have a large domain model, it can be very beneficial to disable Hibernate sessionFactory reloading by setting the hibernate.reload = false flag in DataSource.groovy
Something went wrong with that request. Please try again.