The simplest “micro” deployment (ArqTip #2)

read the asciidoc based version of this post here.

The second Arquillian tip is the simplest “micro” deployment. Its a Arquillian deployment that uses the hole project as deployment with no need for adding individual classes, packages or libraries:


public class SimplestDeployment {

    public static Archive<?> createDeployment() {
        WebArchive war = ShrinkWrap.create(ZipImporter.class, "cdi-crud.war").
                importFrom(new File("target/cdi-crud.war")).as(WebArchive.class);
        war.addAsResource("persistence.xml", "META-INF/persistence.xml");//replace with test persistence
        return war;

    CarService carService;

    public void shouldCountCars() {
        assertEquals(carService.crud().count(), 4);

This basically uses a previously builded project as deployment and just replaces its persistence.xml to use a test database.

Compare it with a traditional deployment here.

Of course that this simplicity comes with a price:

1 – Its not a true micro deployment because it uses the hole application. If your application is big the deployment can take considerable time(seconds);

2 – You need to build the application before running the test. Here you lose a big advantage of Arquillian which is to not build the application if a test (even functional tests) has failed.

To overcome problem #2 you can execute the tests in surefire integration-tests phase:


There is an issue from 2012 in Arquillian issue tracker which address this feature of a “simplest deployment”  using a single annotation , see the issue here:

Source code of this post can be found here:


Test your REST endpoints inside the container (ArqTip #1)


read the asciidoc based version of this post here.


Since Arquillian 1.1.9.Final it is possible to get deployment URL even in in-container tests. This enables REST endpoints testing inside the container.

The main advantage of running this kind of test inside the container (same JVM) is that you can call any service/method of your application before making the (test)rest call.

Even better, you can prepare your database or whatever configuration you need before running the test. Here is an example using arquillian persistence (which doesn’t work outside the container – see Arq1077):



public class CrudRestIt {

    @Deployment(name = "cdi-rest.war")
    public static Archive<?> createDeployment() {
        WebArchive war = Deployments.getBaseDeployment();
        MavenResolverSystem resolver = Maven.resolver();
        return war;

    URL basePath;

    public void shouldListCars() {
                queryParam("start", 0).queryParam("max", 10).
                get(basePath + "rest/cars").
                body("", hasSize(4)).//dataset has 4 cars
                body("model", hasItem("Ferrari")).
                body("price", hasItem(2450.8f)).


Note that I have included two libs into the deployment, RestAssured and Gson because both are used inside the test.

As a bonus you can get code coverage of your REST endpoints, something you don’t have when running as client (testable=false a.k.a blackbox):





Test source code can be found here: