Skip navigation


8 Posts authored by: aslak

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.


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

After a long wait we can finally give you some good news..


*drum roll*


Arquillian 1.0.0.Alpha5 has been released!


In the beginning of the cycle we came to the conclusion that the old Arquillian core just did not cut it in respect to where we were heading,

so big parts of it has been rewritten...



Some of the hightlight in this release:


  • DeploymentException assertion


Verify that a @Deployment throws the expected deployment exception using @ShouldThrowException(Exception.class)


   @Deployment @ShouldThrowException(WeldException.class)
   public static WebArchive createTestDeployment() { }


  • Multiple deployments


Define as many @Deployment methods as you may need. If you need them deployed in order, use @Deployment.order. When dealing with multiple @Deployments you have to specify which deployment context a @Test method should run within by using the @OperateOnDeployment("deploymentName"). The deploymentName is specified using With this you can swap between in container testing in one deployment, @RunAsClient in the context of another deployment and back incontainer in the third.


   @Deployment(order = 1, name = "dep1")
   public static WebArchive createTestDeployment() { }

   @Deployment(order = 2, name = "dep2")
   public static WebArchive createTestDeployment2() { }

   @Test @OperateOnDeployment("dep1")
   public void callActive1() throws Exception { }

   @Test @OperateOnDeployment("dep2")
   public void callActive1() throws Exception { }


  • Multiple containers


Deploy multiple deployments to multiple containers in the same test class using @TargetsContainer("containerName") on the @Deployment methods. Combined with @OperateOnDeployment("name") individual @Test methods can now execute in different containers.


   @Deployment(name = "dep1") @TargetsContainer("node-1")
   public static WebArchive createTestDeployment() { }

   @Deployment(name = "dep2") @TargetsContainer("node-2")
   public static WebArchive createTestDeployment2() { }

   @Test @OperateOnDeployment("dep1")
   public void callActive1() throws Exception { }

   @Test @OperateOnDeployment("dep2")
   public void callActive1() throws Exception { }


  • Configurable protocol


Previously the protocol was bound to the container you were running on. The container still has a default, but this can now be overwritten on a pr @Deployment method level by using the annotation @OverProtocol("protocolName").


   @Deployment(name = "dep1") @TargetsContainer("node-1") @OverProtocol("Servlet 3.0")
   public static WebArchive createTestDeployment() { }

   @Deployment(name = "dep2") @TargetsContainer("node-2") @OverProtocol("EJB 3.1")
   public static WebArchive createTestDeployment2() { }

   @Test @OperateOnDeployment("dep1") // in container text execution is done over HTTP
   public void callActive1() throws Exception { }

   @Test @OperateOnDeployment("dep2") // in container text execution is done over RMI
   public void callActive1() throws Exception { }


  • Descriptor deployment


Need to deploy a JMS Queue, or a DataSource? Use the Desciptor deployment. Works the same as a Archive deployment by defining a deployment method with return type Descriptor.


   public static Descriptor createTestDeployment() { }


* Arquillian Drone


A new extension for Web testing. Integrates Arquillian with Selenium, WebDriver and Arquillian Ajocado.


public class AjocadoTestCase
   // load ajocado driver
   AjaxSelenium driver;



Some changes:


  • @Run(AS_CLIENT) @Run(IN_CONTAINER) has been replaced by @RunAsClient. RunMode is default read from @Deployment.testable, but you can override the runmode for a in container deployment using @RunAsClient on the @Test method.
  • New Configuration XML format
  • GlassFish 3.0 support was _replaced_ with 3.1 support.



Big thanks to the Arquillian and ShrinkWrap community for helping us with this release!



A extra goes out to, Karel Piwko for Arquillian Drone, Jason Porter for GlassFish Remote 3.1 container and David R Allen for other random issues


[ Arquillian ] | [ JIRA ] | [ SPI Javadoc, API Javadoc ] | [ Reference Guide ] | [ Release Notes ] | [ Maven Artifacts ]

Europe's first JUDCon is starting off in Berlin next week..


Pete Muir and I will be kick starting JUDCon with a little WarmUp on the 6. October around 19:00 at the Berlin JUG where we will be presenting Seam 3 / CDI and Arquillian to the local Berliners.


On the 7. October at JUDCon, Adrian Cole and I will present "Frictionless integration testing in the cloud" on the Cloud track at 17:30.


The 8. October at JUDCon, Michael Schuetz will present "Seam2: Real integration testing with Arquillian" on the JBossAS 6 and 7 Track at 11:00.


Join us on for these fun days... and don't forget the HackFest on the 7. from 19:00-02:00!





We're happy to announce that the 3. Arquillian Alpha release was just pushed out the official channels.


News in Alpha3 are:


  • JBoss AS Remote 5.0
  • JBoss AS 6.0 M4 ready
  • GlassFish 3.0 Remote
  • Jetty Embedded 6.1 & 7
  • Tomcat Embedded 6.0
  • Weld EE Mock 1.1
  • OSGi Embedded 4.2


A big note for Alpha3 is ARQ-200 : Change version scheme for containers. With this most containers changed their artifact name.

The new scheme is: arquillian-"name"-"type"-"major"[."minor"][."point"]

e.g. arquillian-jbossas-remote-60 -> arquillian-jbossas-remote-6


The version rule is: earliest working version and working up to the next artifact version.

That means arquillian-jbossas-remote-6 should work with 6.5 unless there is another container named arquillian-jbossas-remote-6.5.


See The Complete Container Reference Guide for full description of the containers and their configuration.


If you're interested in the upcoming Arquillian release Road Map, we're now keeping the Jira Road Map up to speed on planned features / releases.



Big thanks to the Arquillian and ShrinkWrap community for helping us with this release!


In alphabetical order: Dan Allen, deruelle_jean, thomas.diesler, agori, Ken Gullaksen, jharting, Sten Aksel HeienNicklas Karlsson, Pete Muir, The specified item was not found., Andrew Lee Rubinger, mwringe.


[ Arquillian ] | [ JIRA ] | [ SPI Javadoc, API Javadoc ] | [ Reference Guide ] | [ Release Notes ] | [ Maven Artifacts ]


Ike Goes Emotional!

Posted by aslak Jul 21, 2010

For the observant viewer, you might have noticed the little colored ball in the top right corner of the Arquillian badge on the Arquillian site. For the not so observant one, this is what it looked like:



The ball is the Hudson build indicator. It tells you the status of the latest Arquillian build.


We're proud to show off our latest build status, so now we're taking it one step further...


Meet Emotional Ike!

SUCCESS: Latest build was a complete success. Ike is pleased!

UNSTABLE: Latest build has failing tests, be careful. Ike is giving you a warning for this time..

FAILURE: Latest build failed. Ike is pissed! If you see this, you should run and hide.

UNKNOWN: For some reason the status of the latest build is unknown. With all the uncertainty and doubt, Ike sings the blues.



So if ever in doubt, head over to the Arquillian site to check out Ike's mood in the right side menu.



Big thanks to cheyenneweaver for the awesome graphics! She should be ennobled for all her great work... I'm not going to say to much, but just maybe one day she will...

Another mark in the calendar for the Arquillian team, 1.0.0.Alpha2 has just been released!

The Second fleet of the first wave has arrived!


(... Ooh boy, what a ride! Our transwarp speed engine went critical, had to eject the core and hustle a local merchant at a nearby tradestation for a new coil. A long story for some other time...)


Highlights of the release:


  • @Run(AS_CLIENT) mode: Arquillian only controls the lifecycle of your @Deployment, the test case executes in your local JVM.   
    • Excellent for testing Remote EJBs, WebServices and web pages.


public class LocalRunServletTestCase
   public static WebArchive createDeployment() 
      return ShrinkWrap.create("test.war", WebArchive.class)

   public void shouldBeAbleToDeployWebArchive() throws Exception
      String body = readAllAndClose(
            new URL("http://localhost:8080/test/Test").openStream());

            "Verify that the servlet was deployed and returns expected result",


<?xml version="1.0"?>
<arquillian xmlns=""




The containers you can depoy to in this release:


  • JBoss AS 6.0 Embedded AS
  • JBoss AS 6.0 Remote
  • JBoss AS 6.0 with lifecycle(start/stop as part of the test run)
  • JBoss AS 5.1 Remote
  • JBoss AS 5.1 wth lifecycle(start/stop as part of the test run)
  • JBoss Reloaded (MicroContainer + VirtualDeploymentFramework)   
    • Test your deployers and MC beans !
  • Weld SE
  • GlassFish Embedded 3.0
  • Apache OpenEJB
  • Apache OpenWebBeans


Arquillian no longer exposes the containers dependencies transitively, so you can control which container point release v. or logging framework the Arquillian integration should use. This might sound more complex at first, but see the "Complete Container Reference" in the Reference Guide for Maven examples on how to set this up for each container.


And what's open source without the community?!


Big thanks to the Arquillian and ShrinkWrap community for helping us with this release!


In alphabetical order: Dan Allen, German Escobar, Ken Gullaksen, Sten Aksel Heien, Alejandro Montenegro, Pete Muir, Jesper Pedersen, Andrew Lee Rubinger, Juergen Zimmermann.


And of course thanks to the Seam 3 team for helping with early SNAPSHOT testing, big help!


Today I bring good news to all the fellow Arquillians out there. We just got our own project site!


The project site is the place to go to find all information about the project. It has the typical items like:


  • Overview
  • About the project
  • Features
  • Downloads
  • Documentation
  • Building from source
  • Links to the:   
    • Community space (SBS)
    • Source control (SVN)
    • Issue tracker (JIRA)
    • CI builds (Hudson)


But to keep things interesting, we've also aggregated rolling information, such as:


  • Latest blog entires from the community blog
  • External articles feed
  • Recent commits in source control (with links to JIRA issues)
  • Ohloh project stats
  • Current build status (The blue orb in the corner of the Ohloh stats)


The Arquillian complements the project site as host of the dynamic community content--our forums (discussions), community articles and blog entries. The information on our old "wiki home page" will eventually be phased out and replaced by the community space + the project site.


See something that's missing? Want something changed? As always we would like the communities feedback on where to go from here. Please don't hesitate to let us know!


Now head over to the Arquillian project site and poke around.


Look for the link on the right to find cool Arquillian swag and a wallpaper for your desktop!

I will use the opportunity to give a big thanks to cheyenneweaver for the great artwork and to dan.j.allen for bringing life to the site! Now, let's get back to those new features!


[ Arquillian Project Site | Arquillian Community Space ]

This post was syndicated from


I'm happy to announce the first alpha release of Arquillian, an open source (ASL v2) framework for running tests in the container. If you want to read more about Arquillian's mission, and how it fits into our vision for testing at JBoss, read Testing Java EE the JBoss way.


It's one thing to unit test your code outside of the container, but what happens when you run it inside? Does it still behave the same? How about testing against container managed resources? This is where Arquillian comes into its own.


With Arquillian it's just as easy to write integration tests as unit tests. In fact, to minimize the burden on you, Arquillian integrates with familiar testing frameworks, allowing reuse of tools such as the JUnit/TestNG support in your favorite IDE, Maven Surefire, Ant - in fact any tool which supports TestNG or JUnit!


To show you just how simple this is, here's an example test case setup using JUnit: (we'll get to the actual test next)


public class TemperatureConverterTestCase {
   public static JavaArchive createTestArchive() {
      return Archives.create("test.jar", JavaArchive.class)
         .addClasses(TemperatureConverter.class, TemperatureConverterBean.class);


By using JUnit's @RunWith annotation, you tell JUnit to use Arquillian as the test controller. Arquillian will then look for a static method marked with the @Deployment annotation, which creates your micro deployment. In the example above we simply deploy a session bean interface and implementation.


Arquillian hooks into your testing frameworks lifecycle and reacts to events. On the before suite and after suite events the container is started/stopped, while on the before class and after class events your micro deployment is deployed to/undeployed from the container.


The test case is started in the local JVM, and then Arquillian overrides the normal test execution and migrates the test so that it's executed inside the container. By the time the test framework calls your @Test annotated method, the test is running inside the container, giving us the possibility to work with container managed resources. Here's the complete test class with JUnit @Test methods.


public class TemperatureConverterTestCase {

   public static JavaArchive createTestArchive() {
      return Archives.create("test.jar", JavaArchive.class)
         .addClasses(TemperatureConverter.class, TemperatureConverterBean.class);

   private TemperatureConverter converter;

   public void shouldConvertToCelsius() {
      Assert.assertEquals(converter.convertToCelsius(32d), 0d);
      Assert.assertEquals(converter.convertToCelsius(212d), 100d);

   public void shouldConvertToFarenheit() {
      Assert.assertEquals(converter.convertToFarenheit(0d), 32d);
      Assert.assertEquals(converter.convertToFarenheit(100d), 212d);



Note how we can use @EJB to inject the session bean from our deployment into the test case for use in our test method - neat!


The Arquillian TestEnricher SPI supports all the injection annotations from Java EE 6 - @EJB, @Resource and @Inject.


This example test case could run in GlassFish, JBoss AS or OpenEJB as there are no container specific code/configuration at all. The choice is yours. You could even test on multiple platforms!


I want to learn more, where should I go from here?


You can follow up with some in depth usage scenarios and tests described in these articles:



We also have reference documentation which walks you through the examples from Arquillian, and shows you how to create your own Arquillian test suite. You might also find the Javadoc useful (API, SPI), especially if you plan on adding support for another container. You can also check out the forums and more articles can be found on our community site. If your interested in chatting to us, please drop by #jbosstesting on

So, what's next?


Some of the things you can expect from Arquillian are:


  • Local run mode -- Sometimes, you don't want to run the test case inside the container itself. A local run mode will be added; a mode where your test controls the deployment but is not deployed as a part of it. This will give you the chance to run a test against, for example, JSF pages or RMI (testing for those nasty Non-Serializable / SessionClosed exceptions).
  • Multiple deployments controlled by same test -- Sometimes your micro deployment is not enough to test on its own and you want to package other components as part of the same deployment. For example, you need to test the interaction between two Web applications.
  • Support for method argument injection -- In the first alpha we only support field injection. In alpha 2 we will be extending the TestEnricher SPI to include support for method argument injection:


public void shouldWithdrawFromAccount(@EJB AccountManager manager)
   throws Exception


  • Test method interceptors -- Another planned enricher SPI is a test method interceptor. With this we can add support for transactions:
public void shouldWithdrawFromAccount(@EJB AccountManager manager)
   throws Exception
  • Convention over configuration -- The micro deployments should be as easy as possible to create, so adding support for common conventions should help speed up the test development. For example we can automatically add all classes in the same package as the test class to the deployment
  • Arquillian controlled resources -- Sometimes the container requires container specific configuration e.g, java.naming.* parameters needed to create a InitialContext. If the test case has to explicitly deal with this, it places the burden for container portability back on the test case author. Arquillian will provide an extension point to add Arquillian created/managed resources:
// auto creation of InitialContext based on running container, remote or local.
private InitialContext context;
// auto creation of URL to a deployed Servlet, including http port/ip etc.
private URL myServletURL;
// the bundle context of a deployed osgi bundle
private BundleContext context;
  • Add support for more containers -- We will plan to support more containers! Currently we have planned: GlassFish 3 (as a remote container), Jetty, Tomcat, Resin, Felix OSGI. (Hey Spring guys, you're welcome to join in too!)
  • Third party integrations -- In the spirit of ease of development, we integrate with existing test frameworks as much as possible, but we are always keen to learn of new frameworks we can integrate with. We already plan to support Selenium for example.
  • Support for other build tools -- Arquillian Alpha1 comes with Maven support. In upcoming releases, we will distribute builds targeted toward other build tools like Ant and Gradle (that shout out is for our resident Gradle expert, Jason Porter).
  • A project page, logo and artwork -- All good things must look good. That's why the design team is hard at work putting together artwork for the Arquillian project page. Stay tuned!


Where can I see Arquillian in use?


Arquillian is a new framework, but it's going to be put right to work as the workhorse to test all the Seam 3 modules. It will also be our recommended solution for testing your Seam application. (We'd love to see the community try it out for testing Seam 2 applications). We'll also replace the current core of the JSR-299 CDI TCK with Arquillian, likely for the 1.1 version of the TCK. (To provide a little history, Arquillian originated from the JBoss Test Harness that was developed by Pete Muir as the foundation of the CDI TCK).


If you have any thoughts on these ideas, or would like to suggest some new avenues we should explore, please contact us on the Arquillian Development.


And, what's open source with out the community?!


A big thanks to the Arquillian and ShrinkWrap community for helping out on this release by being early adopters, joining in on community meetings, general discussions and writing blogs, articles and patches. In alphabetical order: Dan Allen, Steven Boscarine, German Escobar, Jordan Ganoff, Ken Gullaksen, Pete Muir, Jason Porter, Andrew Lee Rubinger. You guys rock!


[ JIRA | SPI Javadoc, API Javadoc | Reference Guide | Release Notes | Maven Artifacts ]


See the original blog entry to view and post comments.

Filter Blog

By date:
By tag: