Having extensive acceptance tests is the basis of delivering high quality releases with very few regressions for long time projects. This is even more true when your environment uses dynamically typed languages and changing requirements. One of our Grails projects is running for several years now and continues to evolve and grow. We are in dire need of more acceptance tests and especially their automated execution. Manual testing is not feasible and our coverage through unit and integration tests is not enough. We have a nice set of Selenium IDE acceptance tests already though. They were executed very infrequently which let some bugs slip through into production.
I want to describe our approach to automated and extensive acceptance testing below:
- We create the acceptance tests using capture & replay with selenium IDE. This is a fast way to exercise a new feature through a repeatable test.
- We think that maintaining the tests in code offers much more flexiblity and is easier to run in continuous integration (CI) than maintaining the selenium IDE html code. So we export the captured test to play nicely with the grails selenium-rc plugin. Kurt Harriger explains the setup and usage of the selenium-rc grails plugin. You need to make some changes to the exported code for everything to work nicely:
- Delete or change package declaration.
- Choose a grails functional test compatible file name like
MyAcceptanceTests.groovy. We use the Junit4 export but Groovy export works also because the difference is only marginal and both must be adjusted in some places.
- Change the class name to match the file name without extension if they are not equal already.
- Change the exported test to extends from
- Add the
@Mixin(SeleniumAware)annotation to the test class.
- Remove the setup and teardown methods.
verifyTrue()and friends with junit assertions.
- Each test has to setup it’s initial state. This leads to independent acceptance tests at the expense of some longer running time but is well worth the cost imho.
- The resulting selenium-rc tests can be run easily using
grails test-app -functionaland thus integration in the build process is pretty straighforward. We currently use ant to wrap the grails calls, but other ways may be more feasible depending on your infrastructure.
The end result is fast creation of acceptance tests and much flexibility setting up the test fixture and maintaining the tests. Using the grails plugin you gain easy execution of the tests on the developer machines and CI servers as well. With extensive automated acceptance tests the danger of regressions is greatly reduced. But be sure to not neglect unit and integration tests!
4 thoughts on “Acceptance testing a grails app with selenium-rc”
The problem with Selenium tests are the result. When the CI fails and you’re not able to reproduce the failures locally, you’ve got a problem.
And in our case this happens more than we like, mostly because of some browser issues.
Something like the results in WebTest from canoo would be nice.