Arquillian Blog

Does the title leave you wondering, why you need integration tests for your deployments ?

If so, let me give you a few examples. Consider you decide to upgrade Kubernetes, deploy a new Zapier
integration or add some authentication capability. In order to ensure your platform works every single
time, all of the above scenarios need to be tested with robust integration tests.

With the advent of microservices and cloud native applications, adding integration or
end-to-end tests to your Kubernetes or OpenShift projects might be challenging and cumbersome especially
when you want to set up the test infrastructure to be as close as possible to production.

Arquillian Community understands this pain, and continuously strive to provide users a seamless
experience for writing integration tests with ease by bringing their tests to the real environment and
deploy with confidence like never before.

With this blog post, we aim at showcasing integration tests for your Kubernetes or OpenShift clusters using just Arquillian Cube. Moving a step further, we also demonstrate building and deploying from scratch, applications with no deployment configuration, leveraging the power of Fabric8 Maven Plugin along with the Arquillian Cube Extension.

The key point here is that if OpenShift or Kubernetes is used as deployable platform in production, your tests are executed in a the same environment as it will be in production, so your tests are even more real than before.

Further, the test cases are meant to consume and test the provided services and assert that the environment is in the expected state.

Deployment Testing Recipes

If, you wish to read no more and see it all in action, head straight to our specially curated
examples to help you get started with ease.

Example 1

Deploying a sample PHP Guestbook application with Redis on Kubernetes from the resource descriptor
manifest file and testing it using Arquillian Cube Extension for Kubernetes and Kubernetes custom assertions.

Source: arquillian-testing-microservices/kubernetes-deployment-testing

Example 2

Deploying a Wordpress and My SQL application to OpenShift from a Template file and testing it using Arquillian
Cube Extension for OpenShift and Fabric8 OpenShift Client.

Source: arquillian-testing-microservices/openshift-deployment-testing

Example 3

Building and deploying a sample SpringBoot GuestBook application with zero deployment configuration using
Fabric8 Maven Plugin and Arquillian Cube Extension .

Fabric8 Maven Plugin aids in building Docker images and creating Kubernetes and OpenShift resource
descriptors for the application that allows for a quick ramp-up with some opinionated defaults and Arquillian
Cube Extension deploys the application from the generated resource descriptors and then executes deployment tests.

Source: arquillian-testing-microservices/zero-config-deployment-test

Step By Step Guide To Writing Deployment Tests

For a more in-depth step by step coverage of deployment testing, continue reading below.

Step 1: Setting Up Kubernetes/OpenShift Cluster

One of the pre-requisites for Arquillian Kube Extension, is to have Kubernetes or OpenShift cluster running on
your host machine.

An easy way to setup Kubernetes or OpenShift cluster locally is using Minikube and Minishift respectively.

Step 2: Adding Arquillian Kube Dependencies to your project

Arquillian Kube Extension provides a black box approach to testing your deployment that neither
mutates the containers (by deploying, reconfiguring etc) nor the Kubernetes/OpenShift resources.

It is used for immutable infrastructure and integration testing, wherein the test cases are meant to,
consume and test the provided services and assert that the environment is in the expected state,
providing you with the confidence that your application will work correctly when deployed on
Kubernetes/OpenShift cluster.

Before we can start writing our tests, we need to define a few dependencies as shown below:

Arquillian Cube BOM – Unified Dependencies

<properties>
    <version.arquillian_cube>${latest_released_version}</version.arquillian_cube>
</properties>

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.arquillian.cube</groupId>
            <artifactId>arquillian-cube-bom</artifactId>
            <version>${version.arquillian_cube}</version>
            <scope>import</scope>
            <type>pom</type>
        </dependency>
    </dependencies>
</dependencyManagement>

Arquillian Cube Requirement

Arquillian optionally provides an `ArquillianConditionalRunner` to control situations under which your tests should be executed by letting you specify the requirements using annotations.
For example, you can use annotations like `@RequiresOpenshift` to skip test when the environment is not prepared to run the tests.

To configure these requirements for your tests, enable the dependency to the following module for your project.

<dependency>
    <groupId>org.arquillian.cube</groupId>
    <artifactId>arquillian-cube-requirement</artifactId>
    <scope>test</scope>
</dependency>

Arquillian Cube Kubernetes (For Kubernetes Deployment)

<dependency>
    <groupId>org.arquillian.cube</groupId>
    <artifactId>arquillian-cube-kubernetes</artifactId>
    <scope>test</scope>
</dependency>

Arquillian Cube OpenShift (For OpenShift Deployment)

<dependency>
    <groupId>org.arquillian.cube</groupId>
    <artifactId>arquillian-cube-openshift</artifactId>
    <scope>test</scope>
</dependency>

Arquillian JUnit

<dependency>
    <groupId>org.jboss.arquillian.junit</groupId>
    <artifactId>arquillian-junit-standalone</artifactId>
    <version>${latest_released_version}</version>
    <scope>test</scope>
</dependency>

Fabric8 OpenShift Client

<dependency>
    <groupId>io.fabric8</groupId>
    <artifactId>openshift-client</artifactId>
    <version>${latest_released_version}</version>
</dependency>

For Fabric8 OpenShift Client, include the above dependency in the pom.xml

Step 3: Writing Deployment Tests

Arquillian Cube extension provides out of the box functionality to create and manage a temporary namespace
per test suite for your tests and then applies all the required kubernetes/openshift resources as defined
in the resource descriptors generated by fabric8 maven plugin for your environment.

Kubernetes/OpenShift resources can then be made accessible within the Test Cases by injecting them using
Arquillian’s @ArquillianResources annotation (see example test below).

@RunWith(Arquillian.class)    (1)
public class ExampleTest {

    @Named("dummy")           (2)
    @PortForward
    @ArquillianResource
    Service dummyService;

    @ArquillianResource       (3)
    OpenShiftClient client;

    @RouteURL("application")  (4)
    @AwaitRoute
    private URL route;

    @Test
    public void service_instance_should_not_be_null() throws Exception {
        assertThat(service).isNotNull();
    }

    @Test
    public void test_at_least_one_pod() throws Exception {
       assertThat(client).pods().runningStatus().filterNamespace(session.getNamespace()).hasSize(1); (5)
    }

    @Test
    public void verify_route_is_configured_and_service_is_accessible() throws IOException {
        assertThat(route).isNotNull();
        OkHttpClient okHttpClient = new OkHttpClient();
        Request request = new Request.Builder().get().url(route).build();
        Response response = okHttpClient.newCall(request).execute();

        assertThat(response).isNotNull();
        assertThat(response.code()).isEqualTo(200);
    }
}

Explained below are the steps for the above snippet of a sample deployment test.

1. Configuring Arquillian Test Runner
   To setup our test environment, we need to tell junit that this test shall be executed as a arquillian junit
   test. This is done by @RunWith(Arquillian.class).
2. Injecting Deployment Resources within Test Cases
   Kubernetes/OpenShift resources can then be made accessible within the Test Cases by injecting them
   using Arquillian’s @ArquillianResources annotation.
   The resource providers available, can be used to inject to your test cases the following resources:
   • A kubernetes client as an instance of KubernetesClient.
   • Session object that contains information (e.g. the namespace) or the uuid of the test session.
   • Services (by id or as a list of all services created during the session, optionally filtered by label)
   • Deployments (by id or as a list of all deployments created during the session, optionally filtered by label)
   • Pods (by id or as a list of all pods created during the session, optionally filtered by label)
   • Replication Controllers (by id or as a list of all replication controllers created during the session,
     optionally filtered by label)
   • Replica Sets (by id or as a list of all replica sets created during the session, optionally filtered by label)
3. The OpenShift extension also provides:
   • An openshift client as an instance of OpenShiftClient.
   • Deployment Configs (by id or as a list of all deployment configs created during the session)
   • Resources can be injected into test cases by id or as a list of all deployments created during the
     session, optionally filtered by label.
4. Injecting Container Resources to access the deployed service
   Test Enrichers like @RouteURL further aid in injection of container resources like route to the deployed service.
   For farbric8 maven plugin to identify the route, @RouteURL should be set to artifactId of the project by
   default, or explicity configured otherwise.
5. Adding Test Cases that assert environment is in the expected state.

Step 4: Using Assertion Libraries

Optionally, using Fabric8 Kubernetes Assertions , a nice library based on assert4j, aids in performing
meaningful and expressive assertions on top of the Kubernetes/OpenShift model.

To enable Fabric8 Kubernetes Assertions in your test, include the following dependency in the pom.xml

<dependency>
    <groupId>io.fabric8</groupId>
    <artifactId>kubernetes-assertions</artifactId>
    <version>${latest_released_version}</version>
    <scope>test</scope>
</dependency>

Once everything is ready, Arquillian Kube runs your tests, enriched with resources required to access service
and finally cleaning up everything after the testing is over.

For more details and available configuration options check arquillian kube documentation.

Building Docker Images and creating Resource Descriptors.

Optionally, if you just have a Java application that you wish you to bring to Kubernetes or OpenShift,
use Fabric8 Maven Plugin to create docker images and resource descriptors for you.

Fabric8 Maven Plugin makes Kubernetes/OpenShift look and feel like an application server to a Java
developer by letting you build and deploy your application from maven just like you would with other
maven plugins.

To enable fabric8 on your existing maven project just type fabric8:setup command which adds the
fabric8-maven-plugin to your pom.xml.

Alternatively, you can manually add the following plugin definition to your pom.xml file:

<plugin>
    <groupId>io.fabric8</groupId>
    <artifactId>fabric8-maven-plugin</artifactId>
    <version>3.5.32</version>

    <!-- Connect fabric8:resource and fabric8:build to lifecycle phases -->
    <executions>
        <execution>
            <id>fmp</id>
            <phase>package</phase>
               <goals>
                    <goal>resource</goal>
                    <goal>build</goal>
                </goals>
        </execution>
    </executions>
</plugin>

For more and complete configuration details check out fabric8 maven plugin documentation.

Summary

With some basic features, simple steps and specially crafted examples as highlighted above, you can easily get started with Arquillian Cube extension to test your applications in real production environments, be it Kubernetes or OpenShift clusters, without worrying about setting up the infrastructure and only focusing on the core test logic.

JPA type converters provide an easy way to define how an entity attribute gets persisted to the database. You can use them to implement lots of different features, e.g. to encrypt your data as I showed in a previous post: How to use a JPA Type Converter to encrypt your data
But writing the type converter is not enough. We also need to make sure, that it is working correctly.

In general, there are two ways to test a type converter. We could write a unit test to check, if the conversion works correctly. But a unit test performs a test of the isolated class without putting it into the real execution environment. That means that we will still not know, if the converter works in one of our applications. If everything is set up correctly, the persistence provider will call the converter before writing to and after reading from the database. So we also need to check if the type converter gets called by the persistence provider and if everything works fine under that condition. We need to test the converter inside of the container we want to use for our application.

We will have a look at how this can be done with Arquillian and its persistence extension.

Something about Arqillian

If you are already familiar with Arquillian, you can skip this part. For all of you who have never worked with Arquillian so far, I just want to give some basic information. You can find a more detailed description at the Arquillian Getting Started guide.

Arquillian is a test framework for in container testing. The idea is to do not mock the container you want to use but to test your code inside of it. This provides the advantage, that you can test if your code will also work in your execution environment and not only in your mocked up test scenario. Arquillian provides lots of functionality to manage the container, inject required resources like EJBs or an EntityManager and make your live much easier.

The Arquillian tests are executed by junit. This is great, because you can use them everywhere, where you can execute junit tests. And that means in your IDE, as part of your build process, on your CI server, simply everywhere.

Object under test

The following code snippet shows the object under test for this example. It is a type converter that encrypts and decrypts a String attribute. The converter gets called by the persistence provider before writing to and after reading from the database. If you want to read more about how this type converter works, check my posting about it.

@Converter
public class CryptoConverter implements AttributeConverter<String, String> {

    private static final String ALGORITHM = "AES/ECB/PKCS5Padding";
    private static final byte[] KEY = "MySuperSecretKey".getBytes();

    @Override
    public String convertToDatabaseColumn(String ccNumber) {
      // do some encryption
      Key key = new SecretKeySpec(KEY, "AES");
      try {
         Cipher c = Cipher.getInstance(ALGORITHM);
         c.init(Cipher.ENCRYPT_MODE, key);
         return Base64.encodeBytes(c.doFinal(ccNumber.getBytes()));
      } catch (Exception e) {
         throw new RuntimeException(e);
      }
    }

    @Override
    public String convertToEntityAttribute(String dbData) {
      // do some decryption
      Key key = new SecretKeySpec(KEY, "AES");
      try {
        Cipher c = Cipher.getInstance(ALGORITHM);
        c.init(Cipher.DECRYPT_MODE, key);
        return new String(c.doFinal(Base64.decode(dbData)));
      } catch (Exception e) {
        throw new RuntimeException(e);
      }
    }
}

Setting it up

Before we can start to write our tests, we need to define a few dependencies. I will only show how to configure the dependencies we need for this example. If you have not already set up arquillian tests for your project, you will have to do a little bit more. Please check the Getting Started guide to learn how to setup arquillian for your project. Don’t be afraid, there is not too much to do.

As you can see in the following snippet, we will use JUnit 4.11, Arquillian 1.1.3.Final, the Arquillian Persistence Extension 1.0.0.Alpha7 and the WildFly Application Server 8.1.0.Final.

<?xml version="1.0" encoding="UTF-8"?>
<project
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"
    xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    
    ...

    <properties>
        <version.junit>4.11</version.junit>
        <version.arquillian>1.1.3.Final</version.arquillian>
        <version.arquillian_persistence>1.0.0.Alpha7</version.arquillian_persistence>
        <version.wildfly>8.1.0.Final</version.wildfly>
    </properties>

    <dependencyManagement>
        <dependencies>
            ...
            <dependency>
                <groupId>org.jboss.arquillian</groupId>
                <artifactId>arquillian-bom</artifactId>
                <version>${version.arquillian}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>

    <dependencies>
        ...
        <dependency>
            <groupId>javax.enterprise</groupId>
            <artifactId>cdi-api</artifactId>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>${version.junit}</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.jboss.arquillian.junit</groupId>
            <artifactId>arquillian-junit-container</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.jboss.arquillian.extension</groupId>
            <artifactId>arquillian-persistence-dbunit</artifactId>
            <version>${version.arquillian_persistence}</version>
            <scope>test</scope>
        </dependency>
    </dependencies>

Writing the tests

There are two things we need to do to setup our test environment. At first, we need to tell junit that this test shall be executed as a junit test. This is done by @RunWith(Arquillian.class).

Additionally, we need to create the test deployment, that will be deployed to the container. Therefore we need to implement at least one method and annotate it with @Deployment. As you can see in the following code snippet, we use ShrinkWrap to create a jar archive deployment. The archive contains the CreditCard entity, the CryptoConverter type converter and the test class. There is no need to include any EJBs or other classes which implement business logic. We can inject the EntityManager into our test case and use it directly to persist and read entities. We will have a more detailed look at it later on.

Additionally, we need to add some manifest resources to create a persistence unit, register the type converter and add an empty beans.xml to activate CDI. Please check the getting started guide to get more information on ShrinkWrap and creating deployments.

@RunWith(Arquillian.class)
public class TestCryptoConverter {

    @Deployment
    public static JavaArchive createDeployment() {
        return ShrinkWrap
                .create(JavaArchive.class)
                .addClasses(CreditCard.class, CryptoConverter.class,
                        TestCryptoConverter.class)
                .addAsManifestResource("META-INF/persistence.xml",
                        "persistence.xml")
                .addAsManifestResource("META-INF/orm.xml", "orm.xml")
                .addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");
    }

After this is done, we can start to write the test cases. At first, we will persist a CreditCard entity and check, if the credit card number gets encrypted by the CryptoConverter. Therefore we inject the EntityManager, create a CreditCard entity and pass it to the persist method of the EntityManager. The validation of the persisted data, is done by the Arquillian persistence extension. We just need to define the data we expect to be written to the database. The expected data is defined in the cc.yml file, which is referenced in the @ShouldMatchDataSet annotation. Because the id attribute is generated by the database, we want to exclude it from the validation. This can be done by referencing it in the excludeColumns attribute of the annotation.

    @PersistenceContext
    private EntityManager em;

    @Test
    @ShouldMatchDataSet(value = "data/cc.yml", excludeColumns = "id")
    public void testEncryption() {
        CreditCard cc = new CreditCard();
        cc.setName("My Name");
        cc.setCcNumber("123456789");

        this.em.persist(cc);
    }

The cc.yml contains the following information.

CreditCard:
  - id: 1
    name: My Name
    ccNumber: egFfkhd8cRh82tvsh3VVUg==

In the second test, we will check if we can search the database for a CreditCard entity with a given credit card number. Therefore we use the @UsingDataSet annotation to seed the database with data defined in the cc.yml file. Now we can use the injected EntityManager to call a named query to search for CreditCard entity with the given number.

    @Test
    @UsingDataSet("data/cc.yml")
    public void testRead() {
        CreditCard cc = this.em
                .createNamedQuery(CreditCard.BY_NUMBER, CreditCard.class)
                .setParameter("number", "123456789").getSingleResult();
        Assert.assertEquals("My Name", cc.getName());
    }

Conclusion

We used Arquillian and the Arquillian Persistence extension to test a JPA type converter. Therefore we injected the EntityManager and used the annotations @ShouldMatchData and @UsingDataSet to validate and seed the database with a yml file.
If you want to try it yourself, you can find the sources on github.
You can run it by calling: git clone https://github.com/thjanssen/JPA2.1.git && cd JPA2.1/CryptoConverter && mvn test

What are your experiences with testing your Java EE application with Arquillian? Please write a comment about it.

Want to learn more about Arquillian, see the Arquillian Guides: http://arquillian.org/guides/

About the author

Thorben Janssen is a senior developer with more than 10 years of experience in Java EE development and architecture. During these years he acted as developer, architect, project and technical lead to create high available, clustered mobile billing solutions and laboratory information management systems.
Visit his blog: http://www.thoughts-on-java.org or follow him on twitter and google+ to read more about Java EE7 and Arquillian.

---

In about a weeks time DevConf 2013 in Brno, Czech Republic will kick of for the 5. year in a row.
This year, as last, we will take part in the HackFest spanning from Saturday 23. to Sunday 24. of February. And for the eager hackers even Monday 25. February.

Introducing the candidates

Without any more fuzz, let’s jump straight into some of the ideas we have for this hackfest. Of course, you’re free to bring your own as well!

Gradle Container Controller

One of the hacks that was started during the Devoxx 2012 Hackergarten: was the Arquillian Gradle integration. The basic idea is to leverage Arquillian’s Container support to control Containers and Deployments within the Gradle build system, much like we do for Maven via the Arquillian Maven Plugin. This in particular is a very interesting integration since it opens up Arquillian to a new type of usage, as a pure Container Controller.

Why would Gradle use Arquillian for this? It’s a simple matter of focus. Gradle care about build systems and don’t have the resources to implement support for all the Containers. Arquillian on the other hand care very much of the Containers and already support much more than Gradle currently do in this area. Perfect combination of two tools with different capabilities.

You can read up on some of the discussions and see look at the early prototype.

The end goal would be to match as much as possible of the Gradle Design docs and have Arquillian be the internal runner.

Arquillian Forge Plugin – Extensions

JBoss Forge is best described by them selves.

A core framework and next-generation shell for tooling and automation at a command line level; with APIs for integration in IDEs, extending built in functionality with plugins, and scripting for automating repetitive tasks, Forge is a tool every open-source developer should be looking at.

A core framework for rapid-application development in a standards-based environment. Plugins / incremental project enhancement for Java EE, and more.

There exists already an Arquillian Plugin for Forge which handles setup of Arquillian Core and Container dependencies, Container configuration and simple TestClass generation.

But the missing bit is set up and support for the Arquillian Extensions. This hack should be able to answer, by using Forge, questions like:

• How do I setup Drone, Persistence, Transactions?
• How do I configure Drone?
• Which configuration options does Persistence support?

Arquillian Warp

Arquillian Warp fills the void between client-side and server-side testing. Using Warp, you can initiate an HTTP request using a client-side testing tool such as WebDriver and, in the same request cycle, execute in-container server-side tests. This powerful combination lets you cover integration across client and server.

SeamTest

Warp leverages any HTTP client (such as httpclient or WebDriver), to produce testable requests and provides server-side hooks which allows you to execute arbitrary logic in any part of the request lifecycle. However the fact that developer needs to provide HTTP request in order to test is limiting – sometimes you need to test using any request type: such as conversations. The goal is designing an API and implementation for testing sequence of requests without providing an HTTP client logic. (This extension should provide a migration layer for SeamTest )

CDI events

Warp plays nicely with IoC principles – your test does not need to tightly couple with container, it will bring all the necessary dependencies to the test. In Java EE, Warp leverages CDI to inject user-defined beans into the test. Warp has the potential to use much more from the concepts brought by CDI: observe CDI events, produce beans or intercept calls to existing beans. The idea is to provide hooks which would make testing of client request interaction with CDI beans as easy as defining Warp’s lifecycle hooks.

Arquillian Google Web Toolkit

The Google Web Toolkit is a development tool for building complex browser-based applications written in pure Java. The new Arquillian GWT extension brings true integration testing to GWT. This means that GWT integration tests can break free and execute in the actual runtime container instead of being tied to GWT’s embedded Jetty server. Further it is now possible to combine GWT client-side and standard in-container tests in the same test class. This allows to test features without having to worry about the client-server bridge and should pave the way for future support of Arquillian Warp and Drone in GWT integration tests.

Remove the need for GwtArchive

Currently the Arquillian GWT extension uses a custom utility (GwtArchive) to enrich WebArchives for GWT deployments. This causes the API for Arquillian GWT tests to deviate from standard Arquillian tests. It should be possible to automatically enhance the deployment archive to include all dependencies and configurations that are relevant to the GWT deployment, possibly by leveraging an Arquillian packaging SPI’s. As a result of this, GWT integration tests will use the same API as all other Arquillian tests.

Leverage Arquillian Warp in GWT integration tests

Warp enables tests to assert on both client-side and server-side logic and is an extremely useful tool for writing compact integration tests. The focus will be on brainstorming to come up with a battle plan for how Warp could be integrated with Arquillian GWT.

Arquillian Distribution Extension

This is probably the hardest and largest of them all. But even more interesting, right?. As Arquillian work today it will allow you to interact with local and remote Containers. But the big assumption with Remote Containers is that the Container is already up and running and we only need to connect to it. As we’re growing out to support more and more advanced use cases we’re starting to see the need for the ability to control and distribute infrastructure. Infrastructure being servers, containers or clouds.

A very brief description of what this extension should do:

• Install Container A on Server B (copy source and configure)
• Install Container X on Server Y (copy source and configure)
• Configure Arquillian to use Container A on Server B
• Configure Arquillian to use Container X on Server Y

From here on Arquillian Test takes over and run tests as described by the Test Suite. Next steps would be:

• Uninstall Container X on Server Y
• Uninstall Container A on Server B

This is particularly useful for the upcoming Performance Extension to allow it to install a full environment, including clients and targets, for performance testing.

What is Arquillian?

Arquillian is open source software that empowers you to test JVM-based applications more effectively. Created to defend the software galaxy from bugs, Arquillian brings your test to the runtime so you can focus on testing your application’s behavior rather than managing the runtime. Using Arquillian, you can develop a comprehensive suite of tests from the convenience of your IDE and run them in any IDE, build tool or continuous integration environment.

When and where are we hacking?

We are going to use the free Hackfest at DevConf 2013 as an opportunity to put our heads together to make progress on these ideas. Here are the details:

• When: Saturday February 23 12:30 – 18:30 CET, Sunday February 24 09:00 – 18:30 CET, Monday February 25 09:00 – 17:00 CET
• Where: Hackfest at DevConf 2013 (Masaryk University, Faculty of Informatics, Brno, Czech Republic)
• Conference URL: http://devconf.cz/
• Hashtag: #hackdevconf and #arquillian
• Lanyrd: http://lanyrd.com/2013/hackdevconf/
• IRC: #arquillian on Freenode

Of course, anyone is welcome to hack on these ideas at anytime from anywhere. This is open source!

Who will be there hacking?

• Karel Piwko (Arquillian Drone Lead)
• Lukáš Fryč (Arquillian Warp & Graphene Lead)
• Dan Allen (Arquillian team member)
• Aslak Knutsen (Arquillian Lead)
• You

Happy hacking!

Kick-off

Each project represented at Hackergarten briefly introduced itself and presented ideas to hack on. The presence of Red Hat community projects was very strong (~75%). We’re happy to report that there was lots of interest in Arquillian. It received the most votes for hacking, with JBoss Forge drawing in the second most.

General impressions

The Hackergarten was held in open areas at the back of the pavilion. The areas gave plenty of privacy, but also gave people freedom to move around. We didn’t have to experience that awkwardness of peeking through a door or the distraction of doors opening and closing. We were able to do demos in one section without affecting hacks or discussions going on in other sections because there was enough ambient noise, mostly music from the trade floor. The wired connections provided by switches at each table removed the distraction of getting on wifi, although it took a bit of time and some shuffling around in the morning to figure all that out.

Once we knew to get everyone plugged into the switches, we were off to the hacking races!

Pictures!

See more pictures in Album 1 and Album 2.

Activity Stream (related to testing)

• At the start of the event, I suggested the hack idea to integrate Arquilliun Drone and FluentLenium to Jan Papoušek
  • Jan and I introduced ourselves to Mathilde Lemee and they got to work on the integration straight away, starting off by sharing with each other how their respective projects worked.
  • By days end, they completed a working integration
  • Mathilde also integrated FluentLenium with Thucydides (“2 CDs”); stay tuned because that integration and the integration with Drone may become one and the same
  • In both cases, the integration with FluentLenium was so straightforward (and thus hackable) because of the nice abstraction layer Mathilde created that handled bootstrapping FluentLenium
• Aslak hacked with Hans Dockter, creator of Gradle, on a gradle deployment plugin that uses Arquillian Containers to handle life cycle of dozens of containers (application servers, servlet containers and beyond)
• Bartosz Majsak hacked on a demo for Arquillian Ape and enhanced Arquillian Transaction to work both in-container and embedded
• I spoke with two of the IntelliJ developers (Peter and Yann) about:
  • a plugin for Arquillian (similar to the Eclipse Arquillian plugin)
  • adding an embedded Forge shell with UI interplay (similar to the JBoss Forge view in JBoss Tools)
• I chatted with Julien Viet about:
  • use of Arquillian for testing portlets in isolation and within the portal container
  • treating the web browser as a “container” to incorporate JavaScript testing into a Drone test (prototype, proposal)
• Later in the day, Julien gave a presentation and demo of Juzu, excited to say it’s tested w/ Arquillian Core and Arquillian Drone
• I brainstormed with Geoffrey De Smet, lead of Drools Planner, about:
  • using rules to handle the filtering decision for tests
  • the role decision tables can play in declaring conditions for which tests to run
  • optimizing test suite execution using Drools Planner and distributing tests over a grid
• I spoke with John Smart about Arquillian Core and Arquillian Drone integration with Thucydides
  • We discussed how much the two projects align and what it would take to integrate
  • We concluded the first step is adding a bootstrap API in Thucydides, which he began to flesh out, that could be hooked to the Arquillian event model and all the integrations with individual test runners can be done once in Arquillian
  • We talked about how Drone could likely provide management of WebDriver
  • John Smart has been busy all week working on a bootstrap API for Thucydides (hacking on it with an ATDD approach, of course)
• Koen Aers gave a demonstration of the JBoss Forge integration in JBoss Tools, talked about each of elements it brings to the Forge experience in the IDE
  • Koen wrote his first “Hello, World” IntelliJ plugin to get spun up and prepare to help with the integration
  • IntelliJ said they would put it on their roadmap and support the effort where possible
• Alex Soto and Bartosz discussed integrating NoSQLUnit into Arquillian Ape (peristence extension)
  • These projects closely align and it pushes Arquillian’s definition of container management forward
  • I told Marek Jelen about Alex’s NoSQLUnit demo of testing MongoDB on OpenShift through the port forwarding setup by JBoss Tools; a blog entry may be in the works;
  • Arquillian + NoSQLUnit has lots of application, one of which may be testing NoSQL backends in the Infinispan project
• Alexis Hassler was busy improving the Arquillian adapter for CloudBees by adding EJB injection support.
• Aslak discussed with JAX-RS lead about using Arquillian for JAX-RS TCK; not likely soon, but Jersey is entertaining idea of using Arquillian to test Jersey (JAX-RS reference implementation)
• I spoke with Paul Bakker briefly about combining the Forge Arquillian plugin and the Forge Arquillian Extension plugin into one code base
• I brainstormed with David Blevins, lead of TomEE, about the role a test suite can play in the early and in-progress development of a specification
  • proposed idea of using a ATDD approach where tests could be not only marked as pending (before a ref impl is in place), but also proposed, open question and alternative
  • agreed that using tests can focus the discussion about the spec, clarify ambiguities & resolve different interpretations
  • John Smart gave a demo of Thucydides and we contemplated using it for the CDI test suite

Wrap-up

As the event wound down, I discussed with Andres Almiray, who organized the Hackergarten, about what went on during the day, whether Hackergarten accomplished his goals. He talked about the importance of giving people a chance to make a concrete contribution, give them a win to take home with them, lower perception of a barrier to contributing. I talked to him about the fact that Hackergarten is a catalyst for ideas, some of which come into play before the event, already successful and is also ongoing throughout the week, so we’ll only know total impact once conference is over. Some ideas take time to soak. I can attest, we’re still hacking ;)

Finally, Arquillian was invited to join the Nighthacking Tour hosted by Steven Chin on on Wednesday night, so look for that coverage when it comes online.

What people were tweeting…

• Bartosz Majsak (@majson) posted: #devoxx #arquillian @aslakknutsen you have some pull requests
• Markus Eisele (@myfear) posted: What could be the next cool #Arquillian feature? creative @aslakknutsen at the #hackergarden http://twitpic.com/bcv2lv
• Alexis Hassler (@AlexisHassler) posted: GREEN BAR on my #arquillian test. Cloudbees Container Adapter is getting further, thanks to @majson & @aslakknutsen
• Aslak Knutsen (@aslakknutsen) posted: Hacking #Arquillian Container control plugin for #SBT & #Leiningen. #Gradle next…
• Jan Papousek (@jan_papousek) posted: @MathildeLemee the first attempt of integration FluentLenium and Arquillian is here https://github.com/papousek/arquillian-extension-fluentlenium
• Mathilde Lemee (@MathildeLemee) posted: integrating FluentLenium to Arquillian Drone with @jan_papousek
• John Smart (@wakaleo) posted: Awesome concentrated hacking session with @MathildeLemee: integrating #thucydides and FluentLenium in less than 10 lines of code.
• Alex Soto (@alexsotob) posted: @majson Back home ty Arquillian guys for treat me as one of your team