The JuZcret application is now finished, but our project is not perfect…
All through the previous blog posts, we have neglected to tell you about Unit Test, and this certainly is not a good practice.
The reason is that we wanted to keep you focused on a specific topic during each step. That’s why it’s only during this last step that we’ll talk about Unit Test in Juzu.
The good news is that Juzu allows you to leverage Selenium easily to simulate a real application while taking advantage of the speed of JUnit.
So it’s time to write Unit Test for our JuZcret portlet. The portlet will be deployed to an embedded portlet container. Selenium WebDriver will help to simulate almost all user interactions with the application, and then Arquillian will help to integrate with JUnit.


Dependencies

We will use:
  • JUnit 4
  • Arquillian: A testing framework for managing containers and writing integration tests
  • ShrinkWrap: Arquillian’s little brother, used for creating Java archives easily
  • Selenium WebDriver: A simple API for simulating browser behavior
  • platform-community-4.1.0-RC1.zip
To make testing easy, Juzu provides Maven dependencies called depchains that contain all needed dependencies for testing an application with the following tools: Juzu, depchain, and Arquillian and Juzu, depchain, Arquillian, and Tomcat7, which should already be in your pom.xml file:
The Juzu core provides some abstract test classes that make it easier for our tests to interact with Arquillian. Let’s add this dependency and plugin:
There are xml parsing library conflicts between htmlunit Webdriver and our eXo JCR. We’ll need to add some “exclusions” tags into the pom.xml file. Update the exo.jcr.component.ext dependency:

Test configuration and mocks

We need to add a configuration file for Arquillian: src/test/resources/arquillian.xml.

Overwrite service implementation

We want to focus only on testing the JuZcret controller, not the JCR service. It’s better to mock the SecretService JCR implementation. The good news is that we already have an in-memory service implementation (remember step 2). The bad news is that, today, we cannot override the service declared in package-info.java in the unit test. For now, we have a workaround, and in the future, we plan to improve the juzu-core unit test support.
Create a mock for a secret service and add it to src/test/java/org/juzu/tutorial/services:
The classloader of the test will load the SecretServiceJCRImpl service instead of the one in the main source. This mock service delegates all the tasks to our in-memory implementation.
Note: If you are using IntelliJ, you may get a “Duplicate class found in the file” warning because we have two instances of SecretServiceJCRImpl in the same package (one in /main and one in /test). Just ignore it.
We also have SessionProviderService and NodeHierarchyCreator, which are the eXo JCR service inpackage-info.java. We don’t need them for the test.
Let’s mock the eXo kernel provider in src/test/java/org/juzu/tutorial:
Note that the provider return null instance is just the mock provider to satisfy the IOC container. We don’t need a JCR service instance in the test.
We also need to register the mock to the service loader by creating src/test/resources/META-INF/services/juzu.inject.ProviderFactory:

Test cases

We decided to have a dedicated test case for each result of the tutorial steps. We’ll simulate all available user interactions with the JuZcret portlet using Selenium.
Note: There are still two actions that cannot simulated for now: changing the language and the portlet mode. This should be improved in a future version.
We will develop our unit test in the JuZcretTestCase.java file in src/test/java/org/juzu/tutorial:
We use the createPortletDeployment method from the abstract test class of juzu-core, which allows us to deploy our portlet in an embedded portlet container.
WebDriver is injected by Arquillian and help to simulate the user interactions.

Test rendering

After step 1, we have a running portlet that renders secretWall.gtmpl. The unit test should help to make a quick test on the results of the rendering process.
Our first test case is very simple:
  • Make the request, get the html body element, and be sure that it contains the substring“JuZcret Portlet.“
  • Print out the whole server response to the console to see the result.

Test adding secret

After step 2, the user can add new secrets. Thanks to Arquillian and WebdDiver, we can easily simulate user input and submit a form in a JUnit test. Let’s add this new test case for adding a secret:
  • We assert that there is no “test secret text” in the secret list.
  • WebDriver provides an API for finding elements in an html page. We find the URL for the add secret page.
  • Find the text area and button, fill out the form, and submit it. All is written using the Java API to simulate the actions. This is a fast and clean way to conduct a UI test.
  • After submitting the add secret form, the portlet will redirect to the home page; note that it may take some time, so we need to tell WebDriver to wait until we have the response from the server by WebDriverWait

Test assets

We have tested for rendering and user interactions. In step 3, we improved the Look&Feel portlet. We should test whether the portlet is served with the correct assets (CSS and JS files) to make sure that all our declarations for assets in package-info.java are correct:
All necessary assets should be in the server response for rendering JuZcret. This test allows us to check that all are present:
Our portlet needs three JavaScript files:
  • js: This file is a juzu-core Ajax script, which provides a jquery plugin to make Ajax requests in our Juzu controller method.
  • js: JQuery is used by script.js and our portlet JS.
  • js: Our application JS file.
The juzcret.less file should be compiled and served as juzcret.css.

Test Ajax actions

In step 5, we add some user interactions that were done using Ajax. Fortunately, HtmlUnit does a good job of simulating a browser. It can execute JavaScript and even Ajax actions.
Note: Remember that we have enables js in arquillian.xml: <property name=”javascriptEnabled”>true</property>
Let’s test the like feature:
The test is pretty simple:
  • Request the index page; click the Like button.
  • Don’t forget to wait until we have a server response; the timeout is 10 second.
The last test is the comment feature test case:
  • Check that no comment with the substring “test comment” already exists.
  • Add a new comment with the message “test comment.”
  • Click on the button to submit the new comment.
  • Don’t forget to wait until we have a server response; the timeout is 10 seconds.
Now our JuZcret application is complete.
Perform a clean install:
Ensure that all tests have succeeded.
The final source of step 7 is available for download on Github.
This blog post is the last of the series of posts about Juzu.
Apprentice, you can be proud. You are now a true Juzu developer with the capability to develop more and more funny Juzu applications and evangelize Juzu to everyone around you.
If you have any questions, head to the Juzu forum; we would be pleased to help you.
If you want to contribute to Juzu, here is the Github repo. Please don’t hesitate to contact us.