Arquillian Portal Extension 1.1.0.Alpha1 Released

The Arquillian team is proud to announce the 1.1.0.Alpha1 release of the Arquillian Portal Extension component!

You may have noticed that we jumped from 1.0.0.CR1 to 1.1.0.Alpha1! No, we’re not going crazy, but given the stability inherit within 1.0.0.CR1 and the changes we were
looking to introduce into the extension, it made sense to bump the version to 1.1.0.

This release contained quite a large amount of changes, compared to previously.

Some of the highlights in this release

GateIn and Pluto portlet container implementations are now included as implementations of the portal extension instead of being in separate repositories.

Add the ability to run integration testing against the portlet containers, and different servlet containers.

Extend Warp to cater for regular and JSF Portlets.

Warp extensions for portlets

For non JSF portlets we can specify an Inspection method with either @BeforePortletPhase or @AfterPortletPhase to specify whether we want to the method executed before or after the particular PortletRequest specified by the value on the annotation. An example of executing an inspection after a RenderRequest would be:

@AfterPortletPhase(Phase.RENDER)
public void afterRender() {
    assertTrue(true);
}

It’s also possible to inject the request and response objects into the Inspection. You can choose to either use a generic PortletRequest or more specific request types based on the portlet lifecycle phase, such as ActionRequest. Here’s an example:

@ArquillianResource
ActionResponse actionResponse;

@BeforePortletPhase(Phase.ACTION)
public void beforeActionRequest() {
    String[] values = actionResponse.getRenderParameterMap().get("data");
    assertNull("Render parameter for data should not be set.", values);
}

@AfterPortletPhase(Phase.ACTION)
public void afterActionRequest() {
    String[] values = actionResponse.getRenderParameterMap().get("data");
    assertTrue("Render parameter for data should be set.", values.length == 1);
    assertEquals("Render parameter set to incorrect value.", BasicPortlet.ACTION, values[0]);
}

For JSF portlets we can still use @BeforePortletPhase and @AfterPortletPhase, but these don’t allow us to inspect the JSF lifecycle. To perform inspection on the JSF lifecycle, we need to use @PortletPhase in combination with the JSF lifecycle annotations from Warp. To inspect when JSF changes the value of a bean on form submission for a portlet:

@ManagedProperty("")
Bean bean;

@PortletPhase(ACTION) @BeforePhase(Phase.UPDATE_MODEL_VALUES)
public void testBeanValueBeforeUpdate() {
    assertEquals("Bean value should not be updated yet.", "originalValue", bean.getText());
}

@PortletPhase(ACTION) @AfterPhase(Phase.UPDATE_MODEL_VALUES)
public void testBeanValueAfterUpdate() {
    assertEquals("Bean value should now be updated.", "newValue", bean.getText());
}

One point of note when writing Warp tests for portlets is that most portlet containers perform a redirect after an Action or Event request, but before the portlet is rendered. To be able to inspect on both an Action and Render request, we need to use Warp request groups:

Warp
    .initiate(new Activity() {
        public void perform() {
            // Do something
        }
    })
    .group()
        .observe(request().index(1))
        .inspect(new Inspection() {
            private static final long serialVersionUID = 1L;

            @PortletPhase(ACTION) @BeforePhase(Phase.UPDATE_MODEL_VALUES)
            public void testBeanValueBeforeUpdate() {
                // Asserts
            }
        })
    .group()
        .observe(request().index(2))
        .inspect(new Inspection() {
            private static final long serialVersionUID = 1L;

            @PortletPhase(RENDER) @BeforePhase(Phase.RENDER_RESPONSE)
            public void testBeanValueBeforeRenderResponse() {
                // Asserts
            }
        })
    .execute();

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 Portal Extension
Version 1.1.0.Alpha1 view tag
Release date 2013-10-31
Released by Ken Finnigan
Compiled against

Published artifacts org.jboss.arquillian.extension

  • org.jboss.arquillian.extension » arquillian-portal-shrinkwrap-api jar javadoc pom
  • org.jboss.arquillian.extension » arquillian-portal-shrinkwrap-impl jar javadoc pom
  • org.jboss.arquillian.extension » arquillian-portal-api jar javadoc pom
  • org.jboss.arquillian.extension » arquillian-portal-spi jar javadoc pom
  • org.jboss.arquillian.extension » arquillian-portal-impl-base jar javadoc pom
  • org.jboss.arquillian.extension » arquillian-portal-impl-gatein jar javadoc pom
  • org.jboss.arquillian.extension » arquillian-portal-impl-pluto-container jar javadoc pom
  • org.jboss.arquillian.extension » arquillian-portal-impl-pluto-jetty-bom pom
  • org.jboss.arquillian.extension » arquillian-portal-impl-pluto-jsf jar javadoc pom
  • org.jboss.arquillian.extension » arquillian-portal jar javadoc pom
  • org.jboss.arquillian.extension » arquillian-portal-warp-api jar javadoc pom
  • org.jboss.arquillian.extension » arquillian-portal-warp-portlet jar javadoc pom
  • org.jboss.arquillian.extension » arquillian-portal-warp-jsf jar javadoc pom

Release notes and resolved issues 4

Feature Request
  • ARQ-1539 - Support for Warp testing with Portlets
Task
  • ARQ-1540 - Migrate implementations into Portal Extension
  • ARQ-1542 - Add integration testing to portal extension

Thanks to the following list of contributors: Ken Finnigan