Arquillian Blog

Mark the date, October 2, 2011: Arquillian wins a Duke’s Choice Award for Innovative Integration Testing at JavaOne 2011!

Is there a better way to start of a though week then to get a solid acknowledgement for the hardwork that you have already put in? I can’t think of any…

Members of the Arquillian team receiving the Duke’s Choice Award (Andrew Lee Rubinger, Dan Allen and Aslak Knutsen).

We accept this award as an ongoing challenge to innovate. We’ll continue our mission to explore strange new testing gaps, seek out new integration points and boldly go where no integration testing software has gone before. This award goes out to the entire Arquillian community: coders, bloggers and evangelists. Excellent work!

After receiving the award, we were invited as guests on the Java Spotlight podcast, which was recorded on site at JavaOne, to talk about Arquillian. You can find our interview at 11:02 into Episode 51 in the series.

We’d also like to congratulate the other Duke’s Choice Award winners as well: dooApp, Inductive Automation, jHome, JFrog, JRebel, LMAX, Rockwell Automation and one of our own, Netty. Great work! Duke certainly made some great choices this year.

Even with the first beta still on the horizon, Arquillian has already begun to transform the enterprise testing landscape, making the formerly untestable testable.

The early influence of the Arquillian project is the result of a legion of community members integrating their diverse skills to flatten the barrier to integration testing. The collaboration across projects and across communities is truly inspiring. It’s safe to say that not only is the Arquillian invasion on, it’s well ahead of its release schedule. And that’s awesome. And the growing community is the reason why.

Noble Ike, the Arquillian prince, and the core project team, would like to recognize the community members that have helped shape Arquillian during each release cycle, either through code contributions, participation or advocacy. For donating their time, effort and patience to make Arquillian a better testing framework for the benefit of the community, we award each of them the title Arquillian Noble.

The Arquillian Nobles page on the project site lists the recipients along with the contributions they made. Contributors are awarded for either a specific release, or for general support of the project. The names of the community members crowned so far are listed here (for reference):

• Pete Muir
• Cheyenne Weaver
• Karel Piwko
• David Allen
• Andy Gibson
• Jason Porter
• Jesper Pedersen
• Jean Deruelle
• Thomas Diesler
• Stale Pedersen
• Nicklas Karlsson
• Ken Gullaksen
• Alejandro Montenegro
• Adrian Cole
• Paul Bakker
• German Escobar
• Michael Schuetz
• Adam Warski
• Markus Eisele
• Cosmin Martinconi
• John Ament
• Stuart Douglas
• Jordan Ganoff
• Lincoln Baxter III
• Mike Brock

Community members may be crowned multiple times. Once a contributor becomes a team member, subsequent contributions are not listed here (team members are noble by default).

In addition to being listed on the Arquillian Nobles page, we are working to get a crown added to each recipient’s JBoss Community profile so that it is globally visible. We’ll announce when that’s available.

The more container adapters and extensions we create, the more power we put in the hands of the developer, and the better enterprise software will become. Feature transparency FTW!

Thanks to all the Arquillian Nobles, present and future, for making Arquillian awesome and for simplifying testing to child’s play!

If you think doing integration testing is significantly slower, complex or just plain harder than unit testing, think again. In this video, Aslak shows how quickly you can go from an empty directory (0mph) to a project that runs a CDI test inside a managed JBoss AS 7 container (60mph) in under a minute using the Arquillian plugin for JBoss Forge.

Notice that the test cold boots JBoss AS 7, deploys the tests and runs it in-container, then undeploys and shuts down the server in < 5 seconds. (It runs even faster when you take away the Maven cycle).

A quote by Brian Leathem is suitable for quoting here:

With tools like Arquillian, Shrinkwrap, [and] in-memory databases, [we] are busting through the old barriers of terms like unit and integration tests. Perhaps we need a new term for them: “real tests” or “useful tests” are two possibilities that come to mind.

Don’t mock. Test for real.

I’m happy to announce that we have moved the Arquillian Reference Guide out of docbook format in the source tree and over to the new JBoss Documentation Confluence instance.

Arquillian Documentation Editor

The old DocBook version has been imported and with a few fixes in the imported wiki code it all seems ok.

From now on, If you find any errors in the formating or content, you can simply just fix it ~:)

Great news! We’ve drastically cut down the number of dependencies that Maven has to download in order to use the JBoss AS 6 remote container adapter Arquillian. You no longer have to download Hibernate just to connect to a remote or managed (standalone) JBoss AS instance ~:)

To cut to the chase, replace this dependency:

<dependency>
   <groupId>org.jboss.jbossas</groupId>
   <artifactId>jboss-as-client</artifactId>
   <version>6.0.0.Final</version>
   <type>pom</type>
</dependency>

with this one:

<dependency>
  <groupId>org.jboss.jbossas</groupId>
  <artifactId>jboss-as-profileservice-client</artifactId>
  <version>6.0.0.Final</version>
  <type>pom</type>
</dependency>

The number of dependencies drops from 318 to just 28! That should save you a heaps of time. Now, Maven doesn’t have download these extra dependenices on the first run, and doesn’t have to resolve the graph on subsequent invocations. You also cut out this unresolved pom warning:

[WARNING] The POM for ws-commons:policy:jar:1.0 is invalid, transitive dependencies
(if any) will not be available, enable debug logging for more details

To make a long story short, the JBoss AS team publishes a stack POM (i.e., BOM) to identify all the dependencies used in JBoss AS. The client POM is a little too well linked and ends up depending on JBoss AS itself somewhere down the line. As you can imagine, this pulls in a lot of transitive dependencies.

The profile service client POM is a trimmed down version that grabs only the libraries needed for communicating with a remote (standalone) JBoss AS instance using the DeploymentManager, which is accessed via the ProfileService.

Cut the internet a break and update your POM today ~:)