Groovy and even more so, Grails, demands automated testing. In fact, extensive coverage is a must to have confidence that we are not regressing or introducing runtime resolution issues with a single errant keystroke. Grails expects you to write tests and each grails project has the familiar test/unit, test/integration and test/functional source folders. Of course, we want to make it as easy as possible to write our tests. You already use a common base class for your grails tests, GrailsUnitTestCase. And it is a well-established practice in environments using testing frameworks such as jUnit to extend this approach to your own needs.
For example, it’s nice to be able to verify failure cases as we discussed in our last post. Perhaps you’re using a helper similar to the one previously described (shown below) in a base unit test class and want to extend its use to integration tests.
def expectThrown(ClassexpectedThrowable = Throwable, Closure closure) { try { closure() } catch(Throwable t) { if (!expectedThrowable.isInstance(t)) { throw t } return t } throw new AssertionError("Expected Throwable $expectedThrowable not thrown") }
Well, if you have the base class in your test/unit source folder, it’s not available to test/integration and test/functional. You can place the base class src/groovy, but then this becomes a production class and is included in your .war file.
The current “solution” actually does start there. Place your base class in src/groovy. Then we want to add an exclusion in BuildConfig.groovy to ensure that this class – and any others you want excluded – are not packaged in the war.
BuildConfig.groovy
grails.war.resources = { stagingDir -> delete(file:"${stagingDir}/WEB-INF/classes/com/carfey/test/CarfeyGrailsTestCase.class") delete(dir:"${stagingDir}/WEB-INF/classes/com/carfey/test") }
Tested against Grails 1.3.7.
1 thought on “Testing in Grails – Common base class for Unit/Integration/Functional Tests”
Comments are closed.