Testing a JSF UI Using Docker

Testing a JSF UI Using Docker

In two previous posts, I wrote about how to test the persistence layer against a Dockerized database and how to test a Java EE application combined with a database both running in a Docker container. Both posts were backend-centric, this one is on the frontend side.

If you are new to Docker or Testcontainers I recommend reading the first post in this series in which Testcontainers gets explained a bit more in detail. 

What We Need:

  • A Docker host, local or remote

  • A Docker image with Wildfly installed

  • Arquillian to deploy to the Dockerized server

  • An Arquillian callback to start the Docker container and configure Arquillian to deploy to it

  • Testcontainers to manage the Docker container.

Overview

A custom Docker image is used which contains Wildfly 14 (kaiwinter/wildfly14-mgmt-user, available on Docker Hub). A management user account allows us to deploy to this server. The deployment is done by wildfly-arquillian-container-remote.

These are the rough steps when a test is started:

1. Unit test is started

2. Arquillian runs our callback

3. Our callback starts the Docker container and configures Arquillian

4. Arquillian deploys the result of the  @Deployment  method

5. Arquillian runs every  @Test  method

The use of Docker is transparent for the test. You can use any existing Arquillian test without changes.

Setup

The tricky part is the dynamic configuration of Arquillian to let it deploy to the Dockerized Wildfly. This is necessary because the server ports are exposed on random ports to the outside of the Docker container to allow the parallel use of multiple instances of the same image. So after the Docker container is running we need to tell Arquillian the exposed management port of Wildfly.

Arquillian is configured by the file arquillian.xml and it cannot be changed by an API dynamically (GitHub Issue). But we can register a org.jboss.arquillian.core.spi.LoadableExtension service (via META-INF/services), which can register a listener on the configuration process.

The listener starts the Docker container and configures Arquillian (see WildflyDockerExtension):

/**
 * Method which observes {@link ContainerRegistry}. Gets called by Arquillian at startup time.
 */
public void registerInstance(@Observes ContainerRegistry registry, ServiceLoader serviceLoader) {
  GenericContainer dockerContainer = new GenericContainer("kaiwinter/wildfly14-mgmt-user:latest")
                                          .withExposedPorts(9990);
  dockerContainer.start();
  configureArquillianForRemoteWildfly(dockerContainer, registry);
}

Test Example

The test looks like a common Arquillian test:

@RunWith(Arquillian.class)
@RunAsClient
public class UserViewTest {

   @Drone
   private WebDriver driver;

   @Deployment
   public static WebArchive createDeployment() {
      // ... WAR creation
   }

   /**
    * Tests if the xhtml page contains a table with five rows.
    */
   @Test
   public void tableContainsData() {
      String address = WildflyDockerExtension.baseUrl + "users.xhtml";
      driver.get(address);
      WebElement datatable = driver.findElement(By.className("ui-datatable-data"));

      List<WebElement> datatableRows = datatable.findElements(By.className("ui-widget-content"));
      assertEquals(5, datatableRows.size());
   }
}

This is the complete example: UserViewTest

Debugging the test

To see if the UI is deployed correctly, set a breakpoint in the test method and open WildflyDockerExtension.baseUrl with the URL of the webpage in a browser (address in the test example above). If the test completes, Testcontainers removes the Docker container so this URL is available only as long as the test is running. If you have problems creating the Arquillian- @Deployment  you may want to bundle your complete application.

Alternatives

Here’s a link to the complete example.

from DZone Cloud Zone

Sharing is caring!

Leave a Reply

Your email address will not be published. Required fields are marked *