This post is the next chapter of My Take Aways from adaptTo() 2018. This time the topic is testing.

Intro

In September 2018 I’ve attended adaptTo() the fifth times in a row 4th times. Unfortunately I missed adaptTo() 2017 but I visited the conf in 2018 again. This year the organizers made the decision to rent a bigger venue in Potsdam, Germany.

adaptTo() is a technical meetup aimed at developers using the Apache Sling, Jackrabbit/Oak and Felix stack. 2018 was the eighth edition. Sessions also covered commercial implementations such as Adobe Experience Manager, with a particular focus on how these products leverage the Sling stack.

adaptTo() 2018 had 25 talks plus lightning talks, a playground session, hands-on labs and about 270 participants.
The slides and source code (if applicable) can be downloaded from the adaptTo() web site: https://adapt.to/2018/en/schedule.html

Below are my take aways from the conference on testing.

The sessions on testing provided a great coverage of the various test levels. They talked about unit and integration testing, API testing, visual frontend testing, performance testing. The knowledge we got is useful not just on Sling/AEM projects, but could be utilized in projects using different platforms. I’ve added the tools, presented in the conference, to the testing pyramid below.

What’s new on testing?

• Toughday – performance testing framework
  • Toughday is a multi-threaded java testing framework to performance/longevity/stress testing. I always thought that this is a specific framework for testing AEM applications. This is true, partly. Toughday contains test suites out of the box to test AEM apps. The suite contains 15% write actions and 85% read actions. However, Toughday itself is a generic testing framework that could be used elsewhere, too.
  • Some of its advantages
    • Tests as code (you can have modularized, versionable java test suite)
    • High performance
    • Ability to integrate into CI/CD pipelines
  • There was a comparision of Toughday with a few alternatives (Gatling, JMeter, Locust) and Toughday looks really impressive taking its features and performance into consideration.
• AET – Automated Exploratory Testing (a product of Cognifide)
  • The goal of AET is website monitoring with automated exploratory testing on the frontend side. It can detect changes in how the web pages are rendered after a push or a release.
  • In my professional experience, visual (frontend) regression test automation is usually completely forgotten or introduced in later phases.
  • The ability to automate visual testing on a project can save a lot of (manual) efforts. It could be integrated into the build pipeline or scheduled to run on regular intervals.
• Karate – HTTP API testing
  • Overview of Karate
    • Open sourced a year ago
    • Currently moving away from Gherkin+Cucumber
    • Readable tests thanks to the BDD style scenario format, native JSON and the intuitive DSL (e.g. HTTP)
    • It can be used for testing Sling based applications by e.g. creating test content via the SlingPostServlet.
    • It provides helper methods to parse the response, e.g. match images in html
    • They’ve developed several utilities for Sling testing (wait Sling ready, cleanup path, etc.)
    • Can be executed with Maven surefire as part of the integration test suite of large multimodule Maven projects
    • Generates human readable HTML test report
    • Can be combined with Gatling to perform stress tests
    • Can also be used for mocking http services
    • See experiments on GitHub on using Karate for HTTP API testing
• JUnit 5 and Sling/AEM Mocks
  • JUnit5 top features the presenter highlighted in the session:
    1. Visibility: no need to make classes, methods public
    2. Assign display names for classes and tests
    3. Group assertions to assert multiple assertions together (assertAll ( assert1, assert2, …))
    4. Exception or timeout handling no longer on @Test annotation but directly inside the test code
    5. Tag tests and execute them by tag
    6. Dependency injection, e.g. AemContext can be injected easily
    7. Conditional test execution (OS, JRE version, etc.)
    8. Repeat test X times by annotating the test method
    9. Parameterized tests (via annotation) run the same tests with different values
       1. Meta annotations: e.g. custom annotation to group several AEM context annotations
    10. Can be constant values, CSV, output of method, …
  • The above list partly matches the 5 top features I found on https://developer.ibm.com/dwblog/2017/best-new-features-junit-5/
    • They also highlight the ability to write parameterized tests that need to be written once and executed with different input values. I find it really cool!
  • Tooling support
    • Surefire, Mockito, large IDEs, Eclipse plugins
  • Sling/AEM Mocks
    • Sling/AEM Mocks support JUnit5 since 8/2018
    • @Rule not required any longer
    • Migration to JUnit5 is easy