Arquillian Blog

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+.

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 Pete’s companion blog entry, 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 it is to write 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):

@RunWith(org.jboss.arquillian.junit.Arquillian.class)
public class TemperatureConverterTestCase {
 
    @Deployment
    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 defines your micro-deployment. In the example above, the micro-deployment contains a session bean interface and implementation, which Arquillian will deploy to the container.

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. Arquillian then 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.

@RunWith(org.jboss.arquillian.junit.Arquillian.class)
public class TemperatureConverterTestCase {
 
    @Deployment
    public static JavaArchive createTestArchive() {
        return Archives.create("test.jar", JavaArchive.class)
            .addClasses(TemperatureConverter.class, TemperatureConverterBean.class);
    }
 
    @EJB
    TemperatureConverter converter;
 
    @Test
    public void shouldConvertToCelsius() {
        Assert.assertEquals(converter.convertToCelsius(32d), 0d);
        Assert.assertEquals(converter.convertToCelsius(212d), 100d);
    }
 
    @Test
    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
• @PersistenceContext
• @Inject

Since there are no container specific code/configuration in this example test case, it’s portable. That means it can be run in GlassFish, JBoss AS or OpenEJB, or all three! The choice is yours.

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:

• Dan Allen – Using Arquillian to test a possible bug in Weld
• Jordan Ganoff – Seam 3 JMS Module Testing with Arquillian
• German Escobar – Testing a JMX Portable Extension for CDI

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 #arquillian on irc.freenode.net

So, what’s next?

Some of the things you can expect from Arquillian in the future 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:

@Test
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:

@Test
@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
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 an 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.
@ArquillianResource
InitialContext context;

// auto creation of URL to a deployed Servlet, including http port/ip etc.
@ArquillianResource(MyServlet.class)
URL myServletURL;

// the bundle context of a deployed osgi bundle
@ArquillianResource
BundleContext context;

• 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 JBoss.org 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 Dev forum.

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 and Andrew Lee Rubinger. You guys rock!

[ Issues | Javadoc: API, SPI | Reference Guide | Release Notes | Maven artifacts ]

This post was syndicated from in.relation.to. See the original blog entry to view older comments.

Recently, we’ve been working hard on a solution to improve the testability of Java EE, and particularly JBoss AS. I’m pleased to say that a critical piece of puzzle, Arqullian, is now available. Congratulations to Aslak and the Arquillian team for releasing the first alpha of Arquillian! You can read more about Arquillian’s mission, and our plans for Java EE testing below; alternatively, there are some quick links at the bottom if you want to dive right in.

The mission of the Arquillian project is to provide a simple test harness that developers can use to produce a broad range of integration tests for their Java applications (most likely enterprise applications). A test case may be executed within the container, deployed alongside the code under test, or by coordinating with the container, acting as a client to the deployed code.

Arquillian defines two styles of container, remote and embedded. A remote container resides in a separate JVM from the test runner. Its lifecycle may be managed by Arquillian, or Arquillian may bind to a container that is already started. An embedded container resides in the same JVM and is mostly likely managed by Arquillian. Containers can be further classified by their capabilities. Examples include a fully compliant Java EE application server (e.g., GlassFish, JBoss AS, Embedded GlassFish), a Servlet container (e.g., Tomcat, Jetty) and a bean container (e.g., Weld SE). Arquillian ensures that the container used for testing is pluggable, so the developer is not locked into a proprietary testing environment.

Arquillian seeks to minimize the burden on the developer to carry out integration testing by handling all aspects of test execution, including:

• managing the lifecycle of the container (start/stop),
• bundling the test class with dependent classes and resources into a deployable archive,
• enhancing the test class (e.g., resolving @Inject, @EJB and @Resource injections),
• deploying the archive to test (deploy/undeploy) and
• capturing results and failures.

To avoid introducing unnecessary complexity into the developer’s build environment, Arquillian integrates transparently with familiar testing frameworks (e.g., JUnit 4, TestNG 5), allowing tests to be launched using existing IDE, Ant and Maven test plugins without any add-ons.

The Arquillian Mission Statement

The first alpha release of Arquillian gives us support for JBoss AS (remote deployments), GlassFish (embedded deployments), Weld SE (embedded deployments) and OpenEJB (embedded deployments). You can also inject beans and component (using @Resource or @Inject) into test cases.

We’ll be adding supported containers in future releases – if you want to see your favorite container on the list, join our community and we can show you how to add support for it. We also plan to add more convention over configuration, meaning you’ll only need to specify a single deployment and reuse it in all your test cases. Aslak has written more about future ideas in a follow-up blog entry announcing the 1.0.0 Alpha 1 release. In that entry he also provides some examples of how to use Arquillian.

We’re strong believers in writing tests, and writing tests which actually test your business logic in the environment it will finally run in, rather than introducing mocked out objects (which may behave differently). While unit testing is important to ensure the correctness of your logic, it does not ensure the correctness of two objects which interact with each other.

With the help of the ShrinkWrap project, Arquillian gives you the ability to create micro-deployments around your tests. Micro-deployments are contained sub-sections of your application logic. This gives you the ability to do lower level integration testing on a lower level then normal integration. It is up to you at what level you want to test!

We also know you need a convenient way to run your test quickly, and that is why we are getting JBoss Embedded AS in shape. Embedded AS offers the potential to bootstrap JBoss AS inside the same JVM when you run your test, making it super easy to debug the test. Unfortunately, Embedded AS support didn’t make this release (we made a decision to release what we have now, rather than delay), but we will push this out to you as soon as it’s ready.

Testing your components and services gets you a long way, but you’ll nearly always want to test your presentation tier as well. And that’s where frameworks like JSFUnit and Selenium come in – they allow you to exercise the work flows your user will use. Support for both these frameworks is planned, as well as for Mock JSF Objects.

If you like what you’ve heard so far, but are worried that Arquillian requires build script wizardry to use, let us surprise you again! Being able to run any of these tests from within the IDE is a key goal of Arquillian — and the key to a rapid development cycle. Arquillian requires no build wizardry! So check out the documentation and give it a try today!

[ Issues | Javadoc: API, SPI | Reference Guide | Release Notes ]

This post was syndicated from in.relation.to. See the original blog entry to view older comments.