Running integration tests with surefire in integration-test phase

The Maven Failsafe Plugin is a fork of the Maven Surefire Plugin designed to help when running integration tests. However, sometimes you may want to use Surefire for integration testing. The situation may be even more complicated if have unit tests and integration tests in the same module. The solution isn’t very pretty but it’s still quite short and understandable…

The Maven Failsafe Plugin is a fork of the Maven Surefire Plugin designed to help when running integration tests. However, sometimes you may want to use Surefire for integration testing. The situation may be even more complicated if have unit tests and integration tests in the same module. The solution isn’t very pretty but it’s still quite short and understandable:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <configuration>
        <skip>true</skip>
    </configuration>
    <executions>
        <!-- run all tests except integration tests -->
        <execution>
            <id>surefire</id>
            <phase>test</phase>
            <goals>
                <goal>test</goal>
            </goals>
            <configuration>
                <skip>false</skip>
                <excludes>
                    <exclude>pl/touk/cc/dao/mybatis/integration/**</exclude>
                </excludes>
            </configuration>
        </execution>
        <!-- run all integration tests -->
        <execution>
            <id>surefire-it</id>
            <phase>integration-test</phase>
            <goals>
                <goal>test</goal>
            </goals>
            <configuration>
                <skip>false</skip>
                <includes>
                    <include>pl/touk/cc/dao/mybatis/integration/**</include>
                </includes>
            </configuration>
        </execution>
    </executions>
</plugin>
You May Also Like

33rd Degree day 3 review

At the last day of the conference, I've decided to skip the first presentations, and get some sleep instead. I was afraid that Venkat's show is going to be too basic, I will see Jacek Laskowski talking about closure at 4Developers, which I'm kind of s...

Simple trick to DRY your Grails controller

Grails controllers are not very DRY. It's easy to find duplicated code fragments in default generated controller. Take a look at code sample below. It is duplicated four times in show, edit, update and delete actions:

class BookController {
def show() {
def bookInstance = Book.get(params.id)
if (!bookInstance) {
flash.message = message(code: 'default.not.found.message', args: [message(code: 'book.label', default: 'Book'), params.id])
redirect(action: "list")
return
}
[bookInstance: bookInstance]
}
}

Why is it duplicated?

There is a reason for that duplication, though. If you move this snippet to a method, it can redirect to "list" action, but it can't prevent controller from further execution. After you call redirect, response status changes to 302, but after method exits, controller still runs subsequent code.

Solution

At TouK we've implemented a simple trick to resolve that situation:

  1. wrap everything with a simple withStoppingOnRender method,
  2. whenever you want to render or redirect AND stop controller execution - throw EndRenderingException.

We call it Big Return - return from a method and return from a controller at once. Here is how it works:

class BookController {
def show(Long id) {
withStoppingOnRender {
Book bookInstance = Book.get(id)
validateInstanceExists(bookInstance)
[bookInstance: bookInstance]
}
}

protected Object withStoppingOnRender(Closure closure) {
try {
return closure.call()
} catch (EndRenderingException e) {}
}

private void validateInstanceExists(Book instance) {
if (!instance) {
flash.message = message(code: 'default.not.found.message', args: [message(code: 'book.label', default: 'Book'), params.id])
redirect(action: "list")
throw new EndRenderingException()
}
}
}

class EndRenderingException extends RuntimeException {}

Example usage

For simple CRUD controllers, you can use this solution and create some BaseController class for your controllers. We use withStoppingOnRender in every controller so code doesn't look like a spaghetti, we follow DRY principle and code is self-documented. Win-win-win! Here is a more complex example:

class DealerController {
@Transactional
def update() {
withStoppingOnRender {
Dealer dealerInstance = Dealer.get(params.id)
validateInstanceExists(dealerInstance)
validateAccountInExternalService(dealerInstance)
checkIfInstanceWasConcurrentlyModified(dealerInstance, params.version)
dealerInstance.properties = params
saveUpdatedInstance(dealerInstance)
redirectToAfterUpdate(dealerInstance)
}
}
}