Arquillian Blog

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

The Arquillian team is proud to announce the 1.0.0.Beta1 release of the Arquillian TestRunner Spock component!

“That’s one small step for man, one giant leap for mankind.”

When you look at list of changes in this release it might not appear as the biggest release in the history of Arquillian Universe, but it’s definitely important one for Spock and Arquillian fans. Big kudos this time go to Karel Piwko and Fabian Schwarzer. Karel gave us a choice between Groovy 1.8 and 2.x and Fabian spotted shortcomings of previous integration approach implemented as global Spock extension. By having those two improvements in place we are getting very close to the final stable release!

Important changes

Annotation driven activation

In order to let Arquillian sneak in to the Spock dimension you’ll need to annotate your Specification using @ArquillianSpecification.

Groovy 1.8 and 2.0

We also updated the Spock and Groovy versions. We guarantee that the following combinations won’t let you down:
* For Groovy 2.x, use spock 0.7-groovy-2.0 or later and Groovy 2.1.4 or later
* For Groovy 1.x, use spock 0.7-groovy-1.8 or later and Groovy 1.8.9 or later

You can always take a look at our examples where we show how to use both versions with Maven.

Both Spock and Arquillian let you test your code with pleasure so wait no more and give it a spin!

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.

Release details

Component	Arquillian TestRunner Spock
Version	1.0.0.Beta1 view tag
Release date	2013-06-20
Released by	Aslak Knutsen
Compiled against	Arquillian Core – 1.0.4.Final Spock – 0.7-groovy-2.0

Published artifacts org.jboss.arquillian.spock

• org.jboss.arquillian.spock » arquillian-spock-core jar javadoc pom
• org.jboss.arquillian.spock » arquillian-spock-standalone jar javadoc pom
• org.jboss.arquillian.spock » arquillian-spock-container jar javadoc pom

Release notes and resolved issues 4

Annotation Driven Spock extension + Support for Spock 0.7 and Groovy 2.0

Feature Request

• ARQ-1143 - Provide support for Groovy 2.0
• ARQ-1144 - Update Spock version to 0.7
• ARQ-1347 - Not possible to run a spock test w/o arquillian

Thanks to the following list of contributors: Karel Piwko, Aslak Knutsen, Bartosz Majsak

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

The Arquillian team is proud to announce the 1.0.0.Alpha3 release of the Arquillian Warp component!

Warp Alpha3 is a last stop to Beta releases which brings mainly enhancements and bug fixes, but also a pretty new documentation:

Documentation Draft

Even though a documentation draft isn’t published yet to the Arquillian site, it is almost completed.

This documentation describes; where Warp’s place in a space of integration testing, how to start with Warp in your project, what features are supported by Warp API and few words about debugging tests and an extension architecture.

Highlighted Enhancements

Jacoco Support

Thanks to Aris Tzoumas, Warp users can now enjoy coverage reporting using arquillian-extension-jacoco. But the contribution was bigger than just that since it enabled a lot of other features.

Meaningful Reporting

The concepts Warp builds upon aren’t really complex, however the implementation needs to make sure that users can understand when something breaks. Warp tries to add as much contextual information as needed to overcome common issues together with a hint on how to resolve an issue.

We hope to improve reporting even more, but here we rely on you – don’t hesitate to report to us when your experience with Warp isn’t as smooth as it should be.

JSF Managed Beans Injection

You can now inject any managed artifact through EL expressions using standard ManagedProperty annotation:

@ManagedProperty(“#{facesContext.application}”) Application application;

@ManagedProperty(“#{myBean}”) SomeFacesBean myBean;

SPI enhancements

Independent Bi-directional Communication

During the Alpha3 development we have identified many common problems which came down to basics that Alpha2 was built upon: piggy-backing on HTTP request/response and wrapping HttpServletResponse.

In order to overcome those problems, Warp now leverages an internal SPI for bi-directional direct communication between test and server (originally created by Aris as a way to support Jacoco).

This is a fundamental change as it changes the way Warp transfers inspections and it also opens up to completely new possibilities by creating a tigher relationship between a test and a server.

Important Bug Fixes

Do not interfere with non-Warp tests

Warp Alpha2 wasn’t really a good citizen and it tried to hook into all tests even though they weren’t annotated with @WarpTest. Those problems should now be addressed.

Enjoy the Release

Alpha3 comes with lot of enhancements which improves the user experience, but it also brings some improvements which were needed to support rising REST and SeamTest migration layer extensions driven by Jakub Narloch and Marek Schmidt.

Let us know if we can smoothly enter a Beta releases train!

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.

Release details

Component	Arquillian Warp
Version	1.0.0.Alpha3 view tag
Release date	2013-06-20
Released by	Lukas Fryc
Compiled against	Arquillian Core – 1.0.4.Final Arquillian Drone Extension – 1.1.0.Final Arquillian Extension Jacoco – 1.0.0.Alpha5 ShrinkWrap Resolver – 2.0.0

Published artifacts org.jboss.arquillian.extension

• org.jboss.arquillian.extension » arquillian-warp-bom pom
• org.jboss.arquillian.extension » arquillian-warp-api jar javadoc pom
• org.jboss.arquillian.extension » arquillian-warp-spi jar javadoc pom
• org.jboss.arquillian.extension » arquillian-warp-impl jar javadoc pom
• org.jboss.arquillian.extension » arquillian-warp-jsf jar javadoc pom

Release notes and resolved issues 24

Bug fixes + Jacoco support

Component Upgrade

• ARQ-1140 - Warp: upgrade LittleProxy to 0.5
• ARQ-1415 - Warp: upgrade to Arquillian Core 1.0.4
• ARQ-1416 - Warp: upgrade to ShrinkWrap resolver 1.0.0

Enhancement

• ARQ-934 - Warp: Reuse manager during whole test
• ARQ-1325 - Warp: replace piggy-backing on request/response with direct test->filter communication
• ARQ-1353 - Warp: propagate manager's context to proxy correctly
• ARQ-1361 - Warp: bring more clarity to ServerResponseTimeoutException failures

Feature Request

• ARQ-1312 - Warp: introduce RequestProcessingDelegationService
• ARQ-1319 - Warp: Jacoco support
• ARQ-1367 - Warp: wrapped response causes NPE
• ARQ-1368 - Warp: reverse order of chaining of request builder
• ARQ-1371 - Warp: enricher allowing to inject JSF managed beans / properties
• ARQ-1386 - Warp: provide a meaningful message when test isn't annotated with @WarpTest
• ARQ-1400 - Failure to create Enrichment hidden by Client Assertion

Bug

• ARQ-1027 - Support CommandService Protocol SPI via Warp Protocol
• ARQ-1291 - Warp: single request execution does enrich only first request
• ARQ-1320 - Warp - The NonWrittingResponse does not override the flushBuffer() method allowing for committing response.
• ARQ-1324 - Warp HTTP request header size beyond reasonable limits
• ARQ-1326 - Warp: the @RunAsClient tests uses proxy even in case the test is not @WarpTest
• ARQ-1365 - Warp: CommandEventBus doesn't support (port) redirects
• ARQ-1369 - Warp: TestContainerToClientChannel sporadically fails
• ARQ-1395 - CommandBusService is started even tho the test is not a @WarpTest
• ARQ-1396 - CommandEventBusService use wrong metadata to match Request URI
• ARQ-1397 - Multiple problems running Warp on WildFly 8.0.0.Alpha1

Thanks to the following list of contributors: Lukas Fryc, Aris Tzoumas, Jakub Narloch, Aslak Knutsen

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

The Arquillian team is proud to announce the 1.0.0.Alpha1 release of the Arquillian Google Guice Extension component!

This is the first release of the Arquillian Guice extension. We’re bringing the next IOC container into the Arquillian universe.

Some of the highlights in this release

Dependency injection

Using this extension setting up a Guice test becomes pretty simple, allowing you to inject all Guice managed dependencies directly into the test case.

Built in Guice deployer

With the help of this extension you don’t need to add Guice to your deployments manually, the extension will take care of that for you.

There are two ways of enabling Guice injection in an Arquillian test case:
The first way is to annotate an Arquillian test case with @GuiceConfiguration. The annotation values allow you to specify the modules that will be passed to the injector instance on creation.

Example test:

@RunWith(Arquillian.class)
@GuiceConfiguration(AppointmentModule.class)
public class AppointmentServiceImplTestCase {

   @Deployment
   public static JavaArchive createTestArchive() {
       return ShrinkWrap.create(JavaArchive.class, "guice-test.jar")
               .addClasses(Appointment.class,
                       AppointmentRepository.class, AppointmentRepositoryImpl.class,
                       AppointmentService.class, AppointmentServiceImpl.class,
                       AppointmentModule.class);
   }

   @Inject
   @Named("appointmentService")
   private AppointmentService appointmentService;

   @Test
   public void testGetAll() {

       Appointment appointment1 = createAppointment("Important", "Work", new Date());
       Appointment appointment2 = createAppointment("Do not forget", "Work", new Date());

       appointmentService.add(appointment1);
       appointmentService.add(appointment2);

       List<Appointment> result = appointmentService.getAll();
       assertNotNull("Method returned null.", result);
       assertEquals("Invalid element count, 2 appointments were expected.", 2, result.size());
   }
}

Where AppointmentModule is defined as fallows:

public class AppointmentModule implements Module {

    public void configure(Binder binder) {

        binder.bind(AppointmentRepository.class)
                .annotatedWith(Names.named("appointmentRepository"))
                .to(AppointmentRepositoryImpl.class);
        binder.bind(AppointmentService.class)
                .annotatedWith(Names.named("appointmentService"))
                .to(AppointmentServiceImpl.class);
    }
}

Guice configuration uses module instances instead of static classes known at compile time, which means that modules can have different state at runtime. Taking that into consideration, static annotation could in some cases be limiting. This is way we added a second possibility for enabling Guice. A static factory method could be added in the test case and annotated with @GuiceInjector that instantiates the Injector directly. The extension will invoke the method prior to test execution and based on the returned injector the dependencies will be available for injection. Is the previous test we would only need to add:

@GuiceInjector
public static Injector createInjector() {

    return Guice.createInjector(new AppointmentModule());
}

The extension defines some pretty simple settings to control how the packaging occur; specify the version of guice to package and if the auto packaging should happen at all.

<extension qualifier="guice">
     <property name="autoPackage">false</property>
     <property name="guiceVersion">3.0</property>
</extension>

We look forward to hearing your feedback about this release in the community forums!

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.

Release details

Component	Arquillian Google Guice Extension
Version	1.0.0.Alpha1 view tag
Release date	2013-06-19
Released by	Aslak Knutsen
Compiled against	Arquillian Core – 1.0.3.Final ShrinkWrap Resolver – 2.0.0-alpha-1

Published artifacts org.jboss.arquillian.extension

• org.jboss.arquillian.extension » arquillian-guice-api jar javadoc pom
• org.jboss.arquillian.extension » arquillian-guice-impl jar javadoc pom
• org.jboss.arquillian.extension » arquillian-guice-bom pom
• org.jboss.arquillian.extension » arquillian-guice-int-tests jar javadoc pom

Release notes and resolved issues 1

Initial release of Arquillian Google Guice Extension

Thanks to the following list of contributors: Jakub Narloch, Aslak Knutsen

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

The Arquillian team is proud to announce the 2.0.0 release of the ShrinkWrap Resolver component!

What is ShrinkWrap Resolver?

The ShrinkWrap Resolvers project provides a Java API to obtain artifacts from a repository system. This is handy to include third party libraries available in any Maven repository in your test archive. ShrinkWrap Resolvers additionally allow you to reuse all the configuration you've already specified in the Maven build file, making packaging of an application archive much easier job.

Release details

Component	ShrinkWrap Resolver
Version	2.0.0 view tag
Release date	2013-06-19
Released by	Karel Piwko
Compiled against	JUnit – 4.8.2

Published artifacts org.jboss.shrinkwrap.resolver

• org.jboss.shrinkwrap.resolver » shrinkwrap-resolver-bom pom
• org.jboss.shrinkwrap.resolver » shrinkwrap-resolver-api jar javadoc pom
• org.jboss.shrinkwrap.resolver » shrinkwrap-resolver-api-maven jar javadoc pom
• org.jboss.shrinkwrap.resolver » shrinkwrap-resolver-depchain pom
• org.jboss.shrinkwrap.resolver » shrinkwrap-resolver-impl-maven jar javadoc pom
• org.jboss.shrinkwrap.resolver » shrinkwrap-resolver-api-maven-archive jar javadoc pom
• org.jboss.shrinkwrap.resolver » shrinkwrap-resolver-spi-maven jar javadoc pom
• org.jboss.shrinkwrap.resolver » shrinkwrap-resolver-spi-maven-archive jar javadoc pom
• org.jboss.shrinkwrap.resolver » shrinkwrap-resolver-impl-maven-archive jar javadoc pom
• org.jboss.shrinkwrap.resolver » shrinkwrap-resolver-spi jar javadoc pom

Release notes and resolved issues 0

Thanks to the following list of contributors: Karel Piwko

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

The Arquillian team is proud to announce the 1.0.0.Beta2 release of the Arquillian Spring Framework Extension component!

It has been a while since that last Arquillian Spring extension release, but it’s finally here. This release focus more on improving existing features rather then introducing completely new ones.

I would like to thank Jakub Kurlenda and John Ament for helping with this release.

Some of the highlights in this release

Managing the Spring’s ApplicationContext lifecycle

New ways of configuring Spring’s context

Warp Spring extension

Deployer new functionality

Managing the Spring’s ApplicationContext lifecycle

Previous versions had one common drawback, each test were running using a separate instance of Spring’s ApplicationContext. Although the ApplicationContext were destroyed and all of its resources were freed after the test execution, this brought additional overhead for each test. From now on the developer has the control whether he want to create only a single context per test case or to have each test run with a new “clean” context, which in some situation might be handy. By default the context will be created only once, but it can easly be changed by adding the @ContextLifeCycle annotation to the test case.

New ways of configuring Spring’s context

This release also bring a couple of new features to ease the test configuration. First are smart defaults used for configuration. Each @SpringConfiguration annotated test do not need to explicitly define the location of the XML file anymore. If no file has been defined, by default the extension will look for file in classpath with exactly the same name as the class located in the class package. The same goes for @SpringAnnotationConfiguration, which now allow to add a static non final internal class which needs to be marked with @Configuration. The extension will use that class by default when configuring Spring.

Example:

@SpringClientAnnotationConfiguration
public class TestCase {

    @Configuration
    public static class ContextConfiguration {

        @Bean
        public EmployeeService employeeService() {
            return new EmployeeServiceImpl();
        }
    }
}

The last new feature is programmatic creation of the ApplicationContext from within a test. From now on it is possible to create the instance of the Spring ApplicationContext for each test via code. This is done by adding a static factory method to the test which needs to be annotated with @SpringContextConfiguration. The extension will invoke this method prior to test execution (all context lifecycle rules mentioned above also apply here) and use it’s result afterwards.

Example:

@SpringContextConfiguration
public static ApplicationContext contextConfiguration() {

   return new ClassPathXmlApplicationContext(
       new String[]{"classpath:service.xml", "classpath:repository.xml"});
}

Why would this be needed? In some cases you needs to have greater control over the context; for instance at the moment this is the only way to pragmatically set the Spring profiles to use for the test. The other possibility could be integration with other frameworks in which the context should not be managed by the test itself.

Warp Spring extension

The Warp Spring extension has been updated to the latest Alpha 2 release. For consistency with other Warp extensions the SpringMvcResult can be now injected using @ArquillianResource annotation. The custom @SpringResource has been deprecated and might be remove in next releases.

Deployer new functionality

The Spring deployer, which is used for automatic packaging the Spring artifacts and enriching the test deployment, has received some updates. It now allows for importing the dependencies directly from the Maven POM file, and could aid with setting up the deployment. The deployer can be configured in the arquillian.xml file through the spring-deployer section. Additional properties like pomFile allow you to specify the location of the pom file to load; useMavenOffline controls the offline mode of the maven resolver in use, and enableCache controls whether the deployer should cache the artifacts in memory. Finally the excludedArtifacts allow you to exclude artifacts that are unwanted from the deployment

<extension qualifier="spring-deployer">

        <property name="importPomDependencies">true</property>

        <property name="pomFile">src/main/resources/test_pom.xml</property>

        <property name="useMavenOffline">false</property>

        <property name="excludedArtifacts">org.jboss.arquillian:*</property>

        <property name="enableCache">true</property>
</extension>

We look forward to your feedback on this new release on the community forums!

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.

Release details

Component	Arquillian Spring Framework Extension
Version	1.0.0.Beta2 view tag
Release date	2013-06-19
Released by	Aslak Knutsen
Compiled against	Arquillian Core – 1.0.4.Final Arquillian Drone Extension – 1.0.0.Final Arquillian Warp – 1.0.0.Alpha2 Arquillian Transaction Extension – 1.0.0.Alpha3 JUnit – 4.8.1

Published artifacts org.jboss.arquillian.extension

• org.jboss.arquillian.extension » arquillian-service-deployer-spring-common jar javadoc pom
• org.jboss.arquillian.extension » arquillian-service-deployer-spring-2.5 jar javadoc pom
• org.jboss.arquillian.extension » arquillian-service-deployer-spring-3 jar javadoc pom
• org.jboss.arquillian.extension » arquillian-service-integration-spring jar javadoc pom
• org.jboss.arquillian.extension » arquillian-service-container-spring jar javadoc pom
• org.jboss.arquillian.extension » arquillian-service-integration-spring-inject jar javadoc pom
• org.jboss.arquillian.extension » arquillian-service-integration-spring-javaconfig jar javadoc pom
• org.jboss.arquillian.extension » arquillian-transaction-spring jar javadoc pom
• org.jboss.arquillian.extension » arquillian-service-integration-spring-2.5-int-tests jar javadoc pom
• org.jboss.arquillian.extension » arquillian-service-integration-spring-3-int-tests jar javadoc pom
• org.jboss.arquillian.extension » arquillian-warp-spring jar javadoc pom

Release notes and resolved issues 16

Improvements

Feature Request

• ARQ-960 - Provide the way to specify the strategy on instantiting AppllicationContext e.g. each test method or each test case
• ARQ-1104 - Spring deployer should include all spring artifacts
• ARQ-1105 - Spring deployer - add maven offline property
• ARQ-1106 - Spring deployer - allow caching the resolved libraries between deployments
• ARQ-1108 - Register the spring transaction provider on the client side.
• ARQ-1134 - Spring deployer - change the implementation of MavenDependencyBuilder.
• ARQ-1269 - Upgrade Spring MVC integration to use Warp 1.0.0.Alpha2.
• ARQ-1270 - Upgrade Spring extension to Arquillian Core 1.0.3
• ARQ-1277 - Allow the SpringMvcResult to be injected through @ArquillianResource.
• ARQ-1304 - Create test ApplicationContext through factory method.
• ARQ-1305 - Defaults values for @SpringConfiguration and @SpringAnnotationConfiguration
• ARQ-1317 - Warp Spring MVC - capture the execution state through HandlerInterceptor
• ARQ-1358 - Define ApplicationContext life cycle events.
• ARQ-1408 - Upgrade Spring extension to Arquillian 1.0.4.Final.

Bug

• ARQ-1079 - SpringEmbeddedApplicationContextProducer testApplicationContext is missing the scope definition.

Thanks to the following list of contributors: Jakub Narloch, Aslak Knutsen, John D. Ament, Jakub Kurlenda