DDevelopment & Design

Integration tests with Maven and JUnit

There is no doubt that integration tests phase is crucial in modern applications development. We need to test behaviour of our subsystems and how they interact with other modules.Using JUnit and Maven it’s quite easy to create integration tests and run…

There is no doubt that integration tests phase is crucial in modern applications development. We need to test behaviour of our subsystems and how they interact with other modules. Using JUnit and Maven it’s quite easy to create integration tests and run them in separate phase than unit test. It is very important, because integration tests tend to take much more time than unit ones because they work with database, network connections, other subsystems etc. Therefore, we want to run them more rarely. With JUnit in version >= 4.8 there are two approaches for creating and running integration test:
* using naming conventions and specifying separate executions for maven-surefire plugin
* create marking interface and mark integration tests with @Category annotation and run test from failsafe-plugin (although it is possible to use surefire in both cases)

Separate executions First method needs naming convention like naming all unit tests with “..Test.java” postfix (or “..Spec.groovy” ;) and integration tests with “..IntegrationTest.java”. Then we need to change maven surefire configuration:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.15</version>
    <configuration>
        <skip>true</skip>    
    </configuration>
</plugin>

What I did here is forcing maven to skip default test phase. Instead of that, I will configure two separate executions (just below the  section):

<executions>
    <execution>
        <id>unit-tests</id>
        <phase>test</phase>
        <goals>
            <goal>test</goal>
        </goals>
        <configuration>
            <skip>false</skip>
            <includes>
                <include>**/*Test.class</include>
                <include>**/*Spec.class</include>
            </includes>
            <excludes>
                <exclude>**/*IntegrationTest.class</exclude>
            </excludes>
        </configuration>
    </execution>
    <execution>
        <id>integration-tests</id>
        <phase>integration-test</phase>
        <goals>
            <goal>test</goal>
        </goals>
        <configuration>
            <skip>false</skip>
            <includes>
                <include>**/*IntegrationTest.class</include>
            </includes>
        </configuration>
    </execution>
</executions>

In unit test execution I include all test that match naming convention for unit tests (both JUnit and spock ones) and exclude files matching integration test pattern and in integration test execution I did something opposite ;)

Annotations

Another method requires defining of marking interface like this:
package info.rnowak.webtex.common.test;

public interface IntegrationTest {

}

Then we can mark our integration test class with:

@Category(IntegrationTest.class)

Next thing is changing of surefire plugin configuration to omit integration test:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.15</version>
    <configuration>
        <includes>
            <include>**/*Test.class</include>
            <include>**/*Spec.class</include>
        </includes>  
        <excludedGroups>info.rnowak.webtex.common.test.IntegrationTest</excludedGroups> 
    </configuration>
</plugin>

What has changed here is new tag with name of interface which marks our integration tests. Next, we need to add and configure maven-failsafe plugin in order to run test from out integration test group:

<plugin><plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-failsafe-plugin</artifactId>
    <version>2.15</version>
    <executions>
        <execution>
            <goals>
                <goal>integration-test</goal>
            </goals>
            <configuration>
                <groups>info.rnowak.webtex.common.test.IntegrationTest</groups>
                <includes>
                    <include>**/*.class</include>
                </includes>
            </configuration>
        </execution>
    </executions>
</plugin>

With this configuration failsafe will run only test marked with @Category(IntegrationTest.class)annotation, no matter what their names are.

What is better? Well, in my opinion it’s just a matter of taste and style. Annotating each integration class may be a little cumbersome but we are not limited to naming classes within specified convention. On the other hand, unit test and integration test usually are named with some convention, so annotations are not a big deal.

— Previous article

Unable to instantiate default tuplizer

Next article —

Recently at storm-users

You May Also Like
DDevelopment & Design

After WHUG meeting

Here are the slides from the talk a gave yesterday. If you have any questions, please ask. Here are the slides from the talk a gave yesterday. If you have any questions, please ask.
DDevelopment & Design

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)
        }
    }
}
DDevelopment & Design

Spring Security by example: securing methods

This is a part of a simple Spring Security tutorial:

1. Set up and form authentication
2. User in the backend (getting logged user, authentication, testing)
3. Securing web resources
4. Securing methods
5. OpenID (login via gmail)
6. OAuth2 (login via Facebook)
7. Writing on Facebook wall with Spring Social

Securing web resources is all nice and cool, but in a well designed application it's more natural to secure methods (for example on backend facade or even domain objects). While we may get away with role-based authorization in many intranet business applications, nobody will ever handle assigning roles to users in a public, free to use Internet service. We need authorization based on rules described in our domain.

For example: there is a service AlterStory, that allows cooperative writing of stories, where one user is a director (like a movie director), deciding which chapter proposed by other authors should make it to the final story.

The method for accepting chapters, looks like this:

Read more »