|

Testing Ajax with Arquillian

ByTomas Zezula

With ever growing demands on a rich and highly interactive user interface across a wide range of devices, automated testing becomes a crucial part of development routine. To my experience, it is often arguable whether the effort spent on writing tests really pays off. Arquillian is a tool I value for its ease of use and overall effectiveness. Today, I would like to share an example of how Arquillian can be used to test an Ajax-driven web application.



To keep the demo easy to follow the application is limited to choosing a preferred color. This idea is not mine. After some googling around I got inspired by an example at Rob’s.

 

The screenshot above shows a home page of a user called demo. Now, the challenge is to ensure the application interacts as expected. As you can see there is a bunch of items on the page we could use in our tests. First of all, the successful login is confirmed by a welcome message. Secondly, the username is displayed in a designated box. Next, notice that a default color is grey. Finally, we keep track of the time the page was last loaded. Since this is supposed to be Ajax, we want the page be fully loaded once and once only.
That calls for a handful of Selenium / Sahi scripts. Well, first things first. Has this actually been deployed yet? With Arquillian, you take control of this initial step in an amazingly elegant manner:
@RunWith(Arquillian.class)
public class SimpleWebTest {
  ..
  import org.jboss.arquillian.junit.Arquillian;
  import org.jboss.arquillian.container.test.api.Deployment;
  import org.jboss.shrinkwrap.api.spec.WebArchive;
  import org.jboss.shrinkwrap.api.ShrinkWrap;
  import org.jboss.shrinkwrap.api.asset.EmptyAsset;
  ..
  @Deployment(testable=false)
  public static WebArchive createDeployment() {
    return ShrinkWrap.create(WebArchive.class, "login.war")
           .addClasses(Credentials.class, User.class, Login.class)
           .addAsWebResource(getFile("login.xhtml"))
           .addAsWebResource(getFile("home.xhtml"))
           .addAsWebInfResource(getFile("faces-config.xml"))
           .addAsWebInfResource(EmptyAsset.INSTANCE, "beans.xml");
  }
  ..
}
Think an enhanced JUnit. Arquillian integrates a number of technologies, each of which is designed for a specific task. ShrinkWrap provides a straightforward and powerful API for assembling Java applications. By using the @Deployment annotation, Arquillian guarantees the application gets deployed before any test is run. What I like in particular is that once the last test is over the deployment is automatically disposed of. All the hassle with the initial setup and the subsequent tear-down boils down to a single annotation. 

To make this happen we have to tell Arquillian where to find the application server. In the arquillian.xml:

<container qualifier="jboss7" default="true">
    <configuration>
      <property name="jbossHome">
         /Users/tom/apps/jboss-as-7.1.1.Final
      </property>
    </configuration>
</container>

Let’s move on the actual testing. The application is powered by JSF 2.0 and all server calls are asynchronous to cater for partial page updates. Testing Ajax could be cumbersome. Fortunately, Arquillian provides an enhanced Selenium extension called Graphene which makes this task really simple:

import org.jboss.arquillian.drone.api.annotation.Drone;
import org.jboss.arquillian.ajocado.framework.GrapheneSelenium;
import static org.jboss.arquillian.ajocado.Graphene.waitForXhr;
import static org.jboss.arquillian.ajocado.Graphene.id;
..
public static final IdLocator CHANGE_COLOR_BUTTON
                          = id("menu:changeColor");
..
@Drone
private GrapheneSelenium browser;
..
// The button click triggers an Ajax request.
waitForXhr(browser).click(CHANGE_COLOR_BUTTON);
// The change is done. Let's test the results
..

Another feature I find extremely useful is the ability to capture screenshots during the test execution. To me, the ability to visually retrospect substantial UI changes increases credibility of the automated testing and adds to overall confidence in the development team. Capturing a screen boils down to a single call:

browser.captureScreenshot();

In fact, it is way too simple. I would expect I could pass a file name as argument. Nevertheless, I was able to work around this limitation by using the ImageIO library: 

import javax.imageio.ImageIO;
..
ImageIO.write(browser.captureScreenshot(), "png",
   new File("screenshots/" + filename + ".png"));
..

Here is an example of what to expect. Notice the highlighted radios:

All in all, I enjoyed using Arquillian and see a great potential in it. The only drawback is a lengthy list of maven dependencies. I won’t bore you with further details, all you need is to read the docs, first two guides will do.

That’s all I wanted to say today. As usual, the source code is attached at the end of the post. Next time, I will look into Arquillian on a mobile platform.


Download Source Code or Explore It

Similar Posts

Featured image
| |

Streamlining Console Output Verification with Kotest

ByTomas Zezula

Console logging is often perceived as a bad practice, but in specific contexts, it’s quite suitable. Consider a scenario of a workshop where printing output directly to the console enhances transparency and simplifies the project setup. Using a comprehensive logger could lead to unnecessary clutter. However, there’s a downside to directly printing to the console—it makes it challenging to verify the result. Well, at least so I thought until I accidentally stumbled upon this awesome article by Thijs Kaper. Although Spring Boot provides out-of-the-box support for output verification, it’s also possible, and sometimes preferable, to implement it independently. In this blog post, I’ll demonstrate how to create a custom spec in Kotest that you can leverage in your tests. This spec automatically captures console output and provides the result for verification.

Insight into Knockout

ByTomas Zezula

Have you ever struggled with lengthy chunks of unwieldy JavaScript code? Tired of chasing down all those subtle intricacies of event-driven asynchronous processing? If you value simplicity and well-structured code Knockout might be an option. Knockout is a JavaScript library utilizing the MVVM pattern to handle UI changes behind the scenes. No  explicit refresh /…

|

SPDY Sample App

ByTomas Zezula

SPDY is a project looking to boast web performance by utilizing the old good HTTP. Established in 2009, SPDY is still considered an experimental protocol supported by a limited number of browsers. The project is fairly well documented and there are examples highlighting the core concepts. When playing with SPDY features, I realized I needed…

|

Make the most of the logs when running Gradle tests

ByTomas Zezula

Both Maven and Gradle generate nicely formatted HTML reports. Moreover, Maven’s Surefire plugin outputs all essential information directly to the terminal. That provides an instant access to stack trace (in case of failures), logs from individual tests etc. Also, there is a nice summary at the end: [bash] ——————————————————- T E S T S ——————————————————- Running com.mycompany.app.AppTest Tests run:…