UI tests using Hobbes.js in AEM

This blog will discuss the usage of the Hobbes.js testing library available in AEM 6.0 and above, to run UI tests from within the browser. This framework technically relies on clientlibs, and the dependencies and categories settings of the clientlibs differentiates them from regular clientlibs.

The 4 quick setup steps:

1. Create a Client Library Folder in the desired location, say, in a component as apps/myProject/components/myComponent/tests.
2. Create Test Suite(s), which are just a collection of similar Test Cases. There can be more than one Test Suite in the Client Library Folder.
3. Specify Test Cases for each Test Suite.
4. Add Actions in each Test Case that will validate (or invalidate) the Test Case.

Once the tests are written, all one needs to do is go to the Developer mode of the Touch UI to execute them.

In-container testing for AEM projects

Nowadays it’s easier than ever to encapsulate the state used by AEM components into objects – commonly referred to as models – which can then be used while rendering the response. For example, the Sling Modelsframework is a great way to do this. If the Sightly format is used for your template, you can only use very simple presentation logic, meaning you must use a model class to do more complex operations.

One of the many benefits of this approach is that your model classes can be automatically tested as part of a continuous integration (CI) set-up. When using Java models, a common approach is to use unit tests to do this, and rely on Mockito or similar frameworks to simulate the behaviour of the AEM environment. Within such a rich environment, however, the test code quickly becomes hard to follow, as most of it is setting up the AEM simulation. Worse still, it’s very easy to get the simulation wrong, meaning your tests pass but your code is actually buggy.

AEM Context JUnit Rule

The AEM mock context can be injected into a JUnit test using a custom JUnit rule named AemContext. This rules takes care of all initialization and cleanup tasks required to make sure all unit tests can run independently (and in parallel, if required).

Example:

public class ExampleTest {

  @Rule
  public final AemContext context = new AemContext();

  @Test
  public void testSomething() {
    Resource resource = context.resourceResolver().getResource("/content/sample/en");
    Page page = resource.adaptTo(Page.class);
    // further testing
  }

}

Read More