[bmajsak]

Heya guys,

I think it makes perfect sense to extract transaction handling out of APE and let it live it's own life. To be honest it shouldn't be responsibility of APE at all (and I'm not really happy about making this decision in the early days :). Since we already have another extension which needs to use transactions I think it's high time to make it happen. Also having it as standalone extension might be useful in another scenarios as Aslak already pointed out.

What I would suggest is to have a look what can be taken from APE implementation and create seperated extension 

* arquillian-service-transaction with API and event handling

* concrete implementations leveraging SPI and implementing interfaces from the core module such as *-spring and *-jta [which might be based on APE code]

Later on I will hook it into the APE code base.

[jmnarloch]

I can take a look into it next week, I think. Currently I'm working on completly different issue.

As mentioned I'm going to move the annotations together with the TransactionHalder, but probably that wouldn't be all that it's need to be done. Maybe we will need to figure out a way for registering the concreate transaction hanlder within the code. So I think that your assitance will be needed and desired.

[jmnarloch]

There is a great set of proposal for extension logo: https://github.com/arquillian/arquillian-artwork/issues/3 made by Sarah.

[jmnarloch]

Hi Bartosz,

I would like to give it a go for refactoring the transaction from APE. I created a repo for that purpose https://github.com/jmnarloch/arquillian-extension-transaction to which you also have access. I think that in couple of days I could create the initial version.

[jmnarloch]

Hi again

I've made very draft version of the transaction module, extracted mostly from the persistence extension if you Bartek will find some time, then please take a look at it. If you find it more appropiate we can open separate discussion regarding only that module.

The code can be found here: https://github.com/jmnarloch/arquillian-extension-transaction

[jmnarloch]

Through last 3 weeks there have been major changes made in the extension so I guess it will be good idea to gather them all in one place.

What have been already done:

• Separation of the test enrichers

The integration capabilities of extension has been moved to entirely separate module. So instead of single arquillian-service-deployer-spring artifact we have:

• arquillian-service-integration-spring
• arquillian-service-integration-spring-inject
• arquillian-service-integration-spring-javaconfig

The core functionality is provided by integration-spring module with two additional extensions. They have been separated in other to allow using them with Spring legacy versions. In result we can use arquillian-service-integration-spring-inject with both Spring 2.5.x and Spring 3 and additional arquillian-service-integration-spring-javaconfig with Spring 3 only.

The arquillian-service-deployer-spring itself is now being used only for packaging the artifacts.

• Warp Spring MVC

This extension has been introduced in order to allow testing Spring MVC controllers running in servlet contaier. It can work together with Arquillian Drone or any other HTTP client.

The configuration requires to substitute the DispatcherServlet with WarpDispatcherServlet.

{code}
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
         version="3.0">
    <servlet>
        <servlet-name>welcome</servlet-name>
        <servlet-class>org.jboss.arquillian.warp.extension.spring.servlet.WarpDispatcherServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>welcome</servlet-name>
        <url-pattern>*.do</url-pattern>
    </servlet-mapping>
</web-app>
{code}

Using Warp we can run functional tests of our web application with additional verification of the server state through ServerAssertion. Example use case:

{code}
@WarpTest
@RunWith(Arquillian.class)
public class LoginControllerTestCase {
    @Drone
    WebDriver browser;
    @ArquillianResource
    URL contextPath;
    @Deployment
    public static WebArchive createDeployment() {
        File[] libs = DependencyResolvers.use(MavenDependencyResolver.class)
                .loadMetadataFromPom("pom.xml")
                .artifacts("org.springframework:spring-webmvc:3.1.1.RELEASE")
                .artifacts("javax.validation:validation-api:1.0.0.GA")
                .artifacts("org.hibernate:hibernate-validator:4.1.0.Final")
                .resolveAsFiles();
        return ShrinkWrap.create(WebArchive.class, "spring-test.war")
                .addPackage(LoginController.class.getPackage())
                .addPackage(UserCredentials.class.getPackage())
                .addAsWebInfResource("WEB-INF/web.xml", "web.xml")
                .addAsWebInfResource("WEB-INF/welcome-servlet.xml", "welcome-servlet.xml")
                .addAsWebInfResource("WEB-INF/jsp/welcome.jsp", "jsp/welcome.jsp")
                .addAsWebInfResource("WEB-INF/jsp/login.jsp", "jsp/login.jsp")
                .addAsLibraries(libs);
    }
    @Test
    @RunAsClient
    public void testGetLogin() {
        Warp.execute(new ClientAction() {
            @Override
            public void action() {
                browser.navigate().to(contextPath + "login.do");
            }
        }).verify(new LoginControllerGetVerification());
    }
    @Test
    @RunAsClient
    public void testLoginValidationErrors() {
        browser.navigate().to(contextPath + "login.do");
        Warp.execute(new ClientAction() {
            @Override
            public void action() {
                browser.findElement(By.id("loginForm")).submit();
            }
        }).verify(new LoginControllerValidationErrorsVerification());
    }
    public static class LoginControllerGetVerification extends ServerAssertion {
        private static final long serialVersionUID = 1L;
        @SpringMvcResource
        private ModelAndView modelAndView;
        @AfterServlet
        public void testGetLogin() {
            assertEquals("login", modelAndView.getViewName());
            assertNotNull(modelAndView.getModel().get("userCredentials"));
        }
    }
    public static class LoginControllerValidationErrorsVerification extends ServerAssertion {
        private static final long serialVersionUID = 1L;
        @SpringMvcResource
        private ModelAndView modelAndView;
        @SpringMvcResource
        private Errors errors;
        @AfterServlet
        public void testGetLogin() {
            assertEquals("login", modelAndView.getViewName());
            assertNotNull(modelAndView.getModel().get("userCredentials"));
            assertEquals("Two errors were expected.", 2, errors.getAllErrors().size());
            assertTrue("The login hasn't been validated.", errors.hasFieldErrors("login"));
            assertTrue("The password hasn't been validated.", errors.hasFieldErrors("password"));
        }
    }
}
{code}

• The embedded container
  

During development when the tests are being frequently modified and continuously re-run using production application server may be overkill. This is were the embedded container can be found usefull. It does not provide the capabilitites of real application server like JNDI or servlet reference implementation, but it still can be used for successfully testing business objects. The execution time of in memory runned tests decreses from seconds into miliseconds.

Changes planned for next release:

There are also two changes that I wish to implement before releasing next version:

• Registering the ApplicationContext on client side

This will be especially usefull when used together with Warp in order to e.g. run tests of REST service.

{code}
@WarpTest
@RunWith(Arquillian.class)
@ClientSpringConfiguration("applicationContext.xml")
public class LoginControllerTestCase {
    @Autowired
    RestTemplate restTemplate;
    // test code
}
{code}

• Transaction support

I find that crucial for making the extension usefull. Ther first steps for extracting the transactions support from Persistence Extension has been made and a working prototype is also ready. Although we still need to discuss the final shape of the transaction support.

Future plans:

• Arquillian Persitence Extension integration
  

The planned integration would allow to set the data source configured through Spring per each test case

• Enabling Spring profiles

Seting which Spring profiles should be made active for the current test case.

[jmnarloch]

After the release of Alpha 2, the next one will include possibility to register the Spring application context on the client side.

Example:

{code}
@RunWith(Arquillian.class)
@SpringClientConfiguration("applicationContext-rest.xml")
public class ClientRestServiceTestCase {
    /**
     * <p>Creates the test deployment.</p>
     *
     * @return the test deployment
     */
    @Deployment
    @OverProtocol("Servlet 3.0")
    public static Archive createTestArchive() {
        return Deployments.createWebApplication()
                .addAsWebInfResource("mvc/web.xml", "web.xml")
                .addAsWebInfResource("mvc/empty.xml", "employee-servlet.xml")
                .addAsWebInfResource("mvc/mvc-applicationContext.xml", "applicationContext.xml");
    }
    /**
     * <p>The context path of the deployed application.</p>
     */
    @ArquillianResource
    private URL contextPath;
    /**
     * <p>Autowired {@link RestTemplate}.</p>
     */
    @Autowired
    private RestTemplate restTemplate;
    /**
     * <p>Tests invocation of a REST service.</p>
     */
    @Test
    @RunAsClient
    public void testGetEmployees() {
        Employee result = restTemplate.getForObject(contextPath + "/Employees/1", Employee.class);
        assertNotNull("The returned result from REST service was null.", result);
        assertEquals("The returned employee has invalid name.", "John Smith", result.getName());
    }
}
{code}

Potential usage would to test REST or SOAP services with Spring configured client.