Month: December 2017

Integration tests with maven

Implementing unit tests with maven is something ordinary and most of us are familiar with the project structure and where the unit tests reside.

However Integration tests are a different case and most of times they have pretty different requirements.
For example it is ok to have your unit tests operate on a h2 in memory database but when it comes to integration tests and complex queries, it is best for them to be executed against an actual relational database like the one used in production.

Considering the above example, chances are that our integration tests might have different configurations and dependencies.

So our goals for our integration tests is to keep them separate from other tests and to execute them separately.

Regarding our maven structure within the source directory we have the main ‘folder’ and test ‘folder’.

In the same fashion we will add an extra directory called ‘it’.
The ‘it’ directory will contain a java directory for our java sources and a resources directory. Same structure with the test directory.

Then we should give instruction to maven on building our code and adding it to our test sources. 

                <plugin>
                    <groupId>org.codehaus.mojo</groupId>
                    <artifactId>build-helper-maven-plugin</artifactId>
                    <version>1.5</version>
                    <executions>
                        <execution>
                            <id>add-test-source</id>
                            <phase>process-resources</phase>
                            <goals>
                                <goal>add-test-source</goal>
                            </goals>
                            <configuration>
                                <sources>
                                    <source>src/it/java</source>
                                </sources>
                            </configuration>
                        </execution>
                    </executions>
                </plugin>

By using the build helper maven plugin we can instruct maven to add extra test source directories to our our build.

The next step is to instruct maven to run our unit tests. To do so we will use the maven failsafe plugin.

The Failsafe Plugin is designed to run integration tests while the Surefire Plugin is designed to run unit tests. The name (failsafe) was chosen both because it is a synonym of surefire and because it implies that when it fails, it does so in a safe way.

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-failsafe-plugin</artifactId>
                <version>2.15</version>
                <executions>
                    <execution>
                        <id>integration-test</id>
                        <goals>
                            <goal>integration-test</goal>
                        </goals>
                    </execution>
                    <execution>
                        <id>verify</id>
                        <goals>
                            <goal>verify</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>

Then to execute the integration tests we should issue.

mvn verify

As expected our integration tests run separately.

To sum up, we want to have integration tests separated from our unit tests. Also we want them to run separately. This can be achieved by utilizing the maven failsafe plugin.
You can find an example project on github.

Advertisement

Run code on startup with Play and Scala

Depending on various projects, sometimes there is the need to execute some actions on initialization just before our application starts to serve requests.

It was a common practice to call the functions that we wanted to get executed through GlobalSettings, however it is not recommended.

The other way around to achieve this is to implement a class which will be injected and thus add the code that we want to get executed on the class constructor.

We might believe that it is sufficient to implement a class which shall use the @Singleton annotation.

For example

@Singleton
class StartUpService {

    //The code that needs to be executed

}

But this will not work as expected since our component instances on play are created lazily when they are needed.

Instances are created lazily when they are needed. If a component is never used by another component, then it won’t be created at all. This is usually what you want. For most components there’s no point creating them until they’re needed. However, in some cases you want components to be started up straight away or even if they’re not used by another component. For example, you might want to send a message to a remote system or warm up a cache when the application starts. You can force a component to be created eagerly by using an eager binding.

To tackle this problem, our singleton has to be initialized eagerly. To achieve an eager initialization we will define an eager binding.

To define an eager binding we have to implement a class that extends the AbstractModule and then bind our service as an eager singleton.

package com.gkatzioura.eager

import com.google.inject.AbstractModule
import com.google.inject.name.Names

// A Module is needed to register bindings
class EagerLoaderModule extends AbstractModule {
  override def configure() = {

    bind(classOf[StartUpService]).asEagerSingleton
  }
}

Then we have to enable our module by declaring so to our conf/application.conf configuration.

play.modules.enabled += "com.gkatzioura.eager.EagerLoaderModule"

The above approach creates a module by defining it explicitly. The other approach is to use the default functionality where Play will load any class called Module that is defined in the root package.

In conclusion, play gives us the option to execute certain functions once the application has started. To do so we need to implement a component as an eager singleton. Skip the GlobalSettings as it is not advised by the official documentation.