CukeSpace or BDD, Arquillian and Java 8

Cucumber supports since few days a Java 8 API.

If you didn’t see it yet here what it looks like (taken from cucumber-java8 tests):

import cucumber.api.Scenario;
import cucumber.api.java8.En;

import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertNotSame;

public class LambdaStepdefs implements En {
    private static LambdaStepdefs lastInstance;

    public LambdaStepdefs() {
        Before((Scenario scenario) -> {
            assertNotSame(this, lastInstance);
            lastInstance = this;
        });

        Given("I have (\\d+) cukes in my (.*)", (Integer cukes, String what) -> {
            assertEquals(42, cukes.intValue());
            assertEquals("belly", what);
        });
    }
}

This is great but does it work with Arquillian?

Start PhantomJS a single time with Arquillian and Drone

Arquillian, Drone, PhantomJS are awesome tools to write UI tests but by default scope of PhantomJS is linked to JUnit scope (class or test). When having a big suite it means Drone will fork a bunch of processes and loose a lot of time starting/stopping PhantomJS…for nothing.

Avoid temp session file with Arquillian Drone

By default drone uses a session file. It is by default created in $HOME and it is not always useful. You can override it by a system property but if you don’t want such a file and can’t wait for the fix (should be in Drone 2) then you can write a small Arquillian extension to skip it:

Arquillian and TomEE embedded: multiple webapps, different CDI extensions

TomEE embedded made several progresses recently and it is nice to use with Arquillian. Since it is fully integrated with Arquillian you can deploy 2, 3 or much more webapps in the TomEE embedded instance…but then you have an issue: CDI. CDI extension mecanism is based on Java ServiceLoader mecanism. It means it uses META-INF/services/* to load its extensions. The issue: TomEE embedded is embedded. Of course it shares its container classloader with all applications but in this case you’ll get in 90% of cases your extension as well (cause of Maven, gradle, …). So it means if you deploy your application with the desired CDI extension and another (a test one) where you don’t want them you’ll get trouble since the extension will be loaded.

How to avoid it?

Arquillian and TomEE: deploy remotely without hacks!

Arquillian is a great way to deploy an application in a container to test it. However the framework itself doesn’t know if the container is local or remote. TomEE adapter (the bridge between arquillian and tomee) was supporting local deployment but remote one was quite hard and needed to workaround a bit arquillian which was not that fancy.

Since yesterday you can do it easily!

Maven and ShrinkWrap/Arquillian made easy?

If you read this post you surely know ShrinkWrap and Maven. The main issue is the boilerplate code needed to create a WebArchive in a Maven project. This is really easier since ShrinkWrap resolver has a correct implementation of the Maven resolver but it still looks useless. All projects end with a ShrinkWrapUtil utility class to do it.

On another side TomEE provides an utility module to ease ShrinkWrap usage called ziplock. It allows you, for instance, to find a File from a class (see JarLocation) or provides you some shortcuts to create Archives (see WebModule). These utilities were created because of TomEE tests need.

However since few days it includes something more general and interesting for any maven user: the Mvn class.

[TIP] TomEE/OpenEJB Arquillian and Maven resolver

New ShrinkWrap Maven resolver is awesome to avoid to handle all dependencies manually but it can be a bit long to resolve dependencies. We just introduced a hack in TomEE and OpenEJB adapters to make it less painful. The idea is quite simple: do the resolution while the container is starting up.

Arquillian Persistence and Embedded container (OpenEJB/DBUnit/HSQLDB case)

Arquillian has a lot of extensions which can dramtically cut needed code. An interesting one is the persistence one which simplifies a lot the DBUnit usage.

The sad part is this extension is designed for not embedded containers….but with this tip you’ll be able to use it (so with OpenEJB, OpenWebBeans, Weld…).

Cuke in Space!, close of a release

Cuke in Space!,  this project aiming to bring cucumber BDD framework to Arquillian. The goal is simple: keep the strength of the Behavior Driven Development adding to it the strength of  Arquillian (portable test writing between containers, deployment control, multi-containers tests…).

Since it is close to a release this post shows important new features you’ll get with it.

What i think about “Arquillian testing guide”

“Arquillian Testing Guide” is a book you can buy on packt publishing website here: Arquillian Testing Guide. I just read it and you’ll find in this article what i liked and what i missed in it.