Arquillian Blog

Since we wrote this post we didn't laze around. Check our latest announcement.

The Arquillian team is proud to announce the 0.0.1 release of the Smart Testing component!

First release of Smart Testing is here!

It all started as a Google Summer of Code project last year with great ground work of our student Dimcho Karpachev.

Flash forward to this summer, after 222 commits, 69 pull requests merged and insane amount of CI builds we are super excited to announce a new addition to Arquillian Universe we’ve been working so vigorously on.

This time it’s not a new extension to Arquillian Testing Platform, but a brand new tool which we hope will bring a breath of fresh air into your builds, let it be on your local machine or the CI server.

You probably know it best – you write some code and tests, run the build, wait few minutes to only see at the later stage that your changes are breaking it. Of course you can go and grab a coffee, but if you commit early and often that might mean caffeine overdose in a very short time. Running tests before pushing is a good practice, but if it takes too long it simply slows you down.

Moreover having long lasting builds on your CI server makes your CI/CD process not really that continuous and leads to Pull Requests piling up. Bringing new features to production with confidence should be seamless. And for this we need to have faster feedback loops.

Smart Testing is a tool that speeds up the test running phase by reordering test execution plan to increase a probability of fail-fast execution and thus give you faster feedback about your project’s health.

That’s why we created this cure for you!

Highlights of this release

With this release we provide following strategies which you can use to optimize your build execution:

• new – gives higher priority to newly added tests
• changed – gives higher priority to changed tests (e.g. new test methods or refactorings of components under tests which imply changes in the tests)
• affected – based on changes in your business logic, gives higher priority to the tests which are exercising them
• failed – gives higher priority to the tests which failed in the previous (local) build

In addition you can either decide to run the whole test suite (ordering mode) or only those tests which fall into the selected categories (selecting, which is also a default mode).

new, changed and affected rely on SCM information. For this release we only support Git.

How to get started

If you are using Maven 3.3.x or newer (and you definitely should!) adding Smart Testing to your build is very easy. Create a file .mvn/extensions.xml in the root of project
with the following content:

<?xml version="1.0" encoding="UTF-8"?>
<extensions>
  <extension>
    <groupId>org.arquillian.smart.testing</groupId>
    <artifactId>maven-lifecycle-extension</artifactId>
    <version>0.0.1</version>
  </extension>
</extensions>

and you are all set!

Executing the build with Smart Testing enabled is as simple as adding one system property with strategies of your choice:

$ mvn clean verify -Dsmart.testing=new,changed,affected

This will execute the build running only those tests which are falling into selected categories, based on your local changes.

For the CI environment, such as Jenkins, you can pass commit hashes using environment variables. For example:
$ mvn verify -Dsmart.testing=affected -Dscm.range.head=GIT_COMMIT -Dscm.range.tail=GIT_PREVIOUS_COMMIT
This will optimize tests based on the changes between the current commit and the one against which the previous build was run.

For more details head over to our documentation backed by awesome Asciidoctor!

We are very excited about Smart Testing but we need you to help us make it even more awesome. We spent tremendous amount of effort building it with the developer experience in mind, but without the community feedback we can only get that far. So give it a try today and tell us what you think! Maven is a first stop for us. Stay tuned! There’s more to come!

Thanks to the whole team for making it happen! You are real heroes!

Also big kudos to Infinitest team for the inspiration! Give it a spin if you are Eclipse or IDEA user.

What is Smart Testing?

Smart Testing is a tool that speeds up the test running phase by reordering test execution plan to increase a probability of fail-fast execution and thus give you faster feedback about your project’s health.

Release details

Component	Smart Testing
Version	0.0.1 view tag
Release date	2017-09-14
Released by	Bartosz Majsak
Compiled against	Arquillian Spacelift – 1.0.2 ShrinkWrap Resolver – 3.0.0-alpha-4

Published artifacts org.arquillian.smart.testing

• org.arquillian.smart.testing » core jar javadoc pom
• org.arquillian.smart.testing » surefire-provider jar javadoc pom
• org.arquillian.smart.testing » junit-test-result-parser jar javadoc pom
• org.arquillian.smart.testing » strategy-affected jar javadoc pom
• org.arquillian.smart.testing » strategy-changed jar javadoc pom
• org.arquillian.smart.testing » strategy-failed jar javadoc pom
• org.arquillian.smart.testing » maven-lifecycle-extension jar javadoc pom
• org.arquillian.smart.testing » git-rules jar javadoc pom
• org.arquillian.smart.testing » smart-testing-test-bed jar javadoc pom

Release notes and resolved issues 30

Initial release with Maven integration.

Component: Core

• #143 All working files (surefire reports, changes) should be placed inside one directory
• #124 Surefire fork failures with our provider
• #109 Removes GlobPatterns logic
• #98 Transitivity in Affected strategy
• #81 ArrayIndexOutOfBounds is thrown when using Surefire 2.20
• #77 Ordering process should take into account previous configuration/strategies
• #75 Affected strategy refactoring
• #52 Git properties

Component: Test Bed

• #138 Exposes all test results from Test Bed build
• #137 Extract git rules to its own module
• #104 Unable to run the same (failing) test twice
• #61 Improve build configuration DSL
• #56 Persisting project under test folder for analysis in case of test failure
• #55 Implement functional tests for failed strategy
• #54 Make smart-testing version and git test bed repo configurable in functional tests
• #53 Ability to configure test project to run failsafe

Component: Maven

• #112 Affected tests are not properly resolved for different surefire fork modes
• #91 Debug information
• #83 NullPointerException is thrown when having custom surefire configuration
• #73 Disable extension when test execution is skipped
• #70 Filter selected tests based on testsToRun first instead of filtering it in selectTests method of TestStrategyApplier
• #69 java.lang.NoSuchMethodError is thrown in case of not defining surefire
• #64 Set configuration defaults
• #62 TestNG Tests in the dogfooding repo giving error when trying to run with specified mode.
• #57 Introduce Maven extension to determine tests to run once before the build starts
• #47 Seamlessly store test results from the build execution
• #44 Build time overhead when running with surefire smart test provider

Component: Documentation

• #74 Smart Testing User Guide

Component: Selection

• #49 Report test selection as a build artifact
• #43 Affected strategy doesn't pick up changes made in the other module

Thanks to the following list of contributors: Bartosz Majsak, Alex Soto, Matous Jobanek, Dipak Pawar, Hemani

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.

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

It’s no suprise we’re obsessed with testing here in the Arquillian Galaxy. We’re eternally interested in sharpening our testing weapons, learning about tools that advance the frontline against the bugs, and discovering all the deep, dark code caves where bugs try to hide from testers.

This year, Devoxx, one of the premier Java developer conferences, is bringing together a large group of testing experts. Listed below are just some of the labs, workshops, and BOFs being presented at Devoxx that will enhance your bug hunting skills.

Monday, November 12, 2012

Tuesday, November 13, 2012

Wednesday, November 14, 2012

Thursday, November 15, 2012

We look forword to hearing what testing tools, techniques and strategies you discover at Devoxx 2012.

Red Hat, Inc. and the JBoss Community today announced the 1.0.0.Final release of Arquillian, its award-winning testing platform built to run on the Java Virtual Machine (JVM). Arquillian substantially reduces the effort required to write and execute Java middleware integration and functional tests. It even enables test engineers to address scenarios previously considered untestable or too expensive to test.

The Arquillian project is led by Aslak Knutsen and has received contributions from over 100 contributors and community members (between Arquillian and ShrinkWrap combined). At the JavaOne 2011 conference, Arquillian received the Duke’s Choice Award for innovation in integration testing.

The 1.0.0.Final release of Arquillian Drone, a key add-on to the platform, is included in this release. Final versions of select container adapters will be released later in the week. ShrinkWrap, a central component of Arquillian, announced its 1.0.0.Final release last week.

Mission and History

Arquillian adheres to three core principles:

• Tests should be portable to any supported container
• Tests should be executable from the IDE to eliminate the need for an explicit build step and to simplify debugging
• The platform should unify the Java testing ecosystem by extending or integrating with existing test frameworks

By focusing on these principles, Arquillian makes integration and functional tests as simple to write and execute as unit tests.

Arquillian originated from the test harness developed for the CDI 1.0 (JSR-299) specification in 2009. It spun off as an independent project and has evolved into an extensible testing platform. Coming full circle, the test suite in CDI 1.1 (JSR-346), the next iteration of the CDI specification, has migrated to Arquillian. Other specifications are expected to follow. Arquillian is also used by numerous open source projects, including Hibernate, JBoss AS 7, Drools, RHQ, JClouds and Apache DeltaSpike.

Functionality

Arquillian brings test execution to the target runtime, alleviating the burden on the developer of managing the runtime from within the test or project build. To invert this control, Arquillian wraps a lifecycle around test execution that does the following:

• Manages the lifecycle of one or more containers
• Bundles the test case, dependent classes and resources as ShrinkWrap archives
• Deploys the archives to the containers
• Enriches the test case with dependency injection and other declarative services
• Executes the tests inside (or against) the containers
• Returns the results to the test runner for reporting

Arquillian runs with Java 1.5 and above, integrates seamlessly with familiar testing frameworks such as JUnit and TestNG and allows tests to be launched using existing IDE, Ant and Maven test plugins.

Loving quotes about Arquillian

…using Arquillian, we were able to cut the setup needed to run a plugin in-container by 90% and we were able to introduce a number of convenience annotations from which you can get a variety of data injected into your tests.”

— Lukáš Krejčí, RHQ core developer

Arquillian is a really great integration testing tool full of potential. It’s just great that the JBoss guys are aiming to provide support for almost all widely used application servers and web containers. If you are writing an application for the Java EE 6 stack, not using Arquillian is a serious mistake!”

— Bartosz Majsak, Cambridge Technology Partners

[Arquillian] reminds me of the old Cactus project back in the day, but done much, much better.”

— Laird Nelson

Newest features

Arquillian can manage more than a dozen container vendors, including JBoss AS, GlassFish and Tomcat, and supports running tests in cloud services. The container support allows developers to target a variety of technology platforms, including Java EE 5 and 6, Servlet environments, OSGi, Embedded EJB and standalone CDI.

Additional new features include:

• Orchestration of multiple deployments across multiple containers in a single test
• Support for multiple protocol contexts within a single deployment
• Descriptor deployment
• Assertions for deployment exceptions
• A new configuration schema that supports multiple configurations per container
• EL-like evaluation in properties and configuration overrides via Java properties
• Explicit ordering of test methods
• Control over when the container is started and stopped

Arquillian’s extensibility is reflected in its growing ecosystem of extensions. The most mature extension, Arquillian Drone, is included in today’s release. Drone is an abstraction over browser controllers such as Selenium and WebDriver that enables the developer to write browser-based tests without having to fuss with the typical setup and plumbing. Other extensions under active development include an Android test controller, DBUnit integration, a SeamTest replacement for testing Seam 2, BDD runners (Spock and JBehave), performance metrics, code coverage (Jacoco) and Arquillian Graphene (a type-safe Selenium API). Expect more extensions to emerge now that the platform has reached a stable release.

Availability

The Arquillian platform and extensions are available in the Maven Central and JBoss Community artifact repositories. The Arquillian libraries are typically added to the test suite of a project using a dependency management tool such as Apache Maven or Apache Ivy. Instructions for setting up Arquillian in your project and writing Arquillian tests are covered in the newly-minted Arquillian Guides.

Arquillian is released under the Apache License, v2.0, an OSI-approved open source software license.

For more information and updates about the Arquilian project, follow the Arquillian project blog and circle the Arquillian project on Google+.