One of our large enterprise clients develops user facing experiences using AEM (Adobe Experience Manager). We can think of AEM as a “WordPress for enterprises”. Developers can author a page using various components.
AEM consists of Author and Publisher instances. Each is a server that listens to ports 4502 and 4503 respectively. The author instance is used for developing and staging pages with content. Using various components, a developer can greatly customize a web page. It is a common pattern to see each team develop their own components to build on top of the existing functionality. A “parsys” is an area that acts as a canvas for adding components on the page. Developers can edit the default properties of each component by updating respective fields in a dialog modal. Once the page is ready to go, a developer clicks “activate” on the siteadmin management interface of the page. This uploads the page to the Publisher instance and makes it live and available to the public.
But how do we test this?
With every software product comes the topic of testing, and developing in AEM is not different. How do we test that the web page is available and is performing as expected? How can we do it in an automated fashion?
There is always the option to use Selenium WebDriver to interact with the page and couple it with some sort of unit test framework that would act as a test runner, but let’s spend some time and discuss what alternatives we might have.
AEM ships with a build-in test framework called HobbsJs. Although it is typically a good idea to use the test framework that is shipped with a development environment, I would argue that it’s not the case here. Hobbs has a number of limitations. To start with, it seems it can only be used in the Developer mode, so it is only beneficial for testing pre-configured component properties. We can’t test authoring and we can’t test publishing. It is impossible to access the navigation bar when you need to switch between different modes.
It’s a different story with Bobcat test framework.
This is a highly AEM centric product. Therefore we were pleased to find a lot of neat features that help to drive the page test automation. Think of it as a great combination of Selenium WebDriver plus helpers to perform AEM specific actions.
On the authoring side this framework supplies us with methods to manage page creation, activation, deletion, checking if it is present in the sideadmin tree. Use siteadminPage instance variable for that.
Ideally you would want to create a test page before each individual scenario, use it, and destroy it at the end of the scenario regardless of whether it finished with success or failure. You can achieve this setup using before and after scenario hooks.
Given that the page is open we can use other Bobcat helpers to interact with parsys by dragging or removing components. Once the component is on the parsys we can edit its properties. Again all of this is done programmatically using the helpers provided to us. No coding necessary.
The webdriver.properties file tester can specify settings for webdriver “capabilities” and default page timeout time. In the instances.properties files we can provide Bobcat with AEM instance urls and login information. It’s not a great idea to hardcode the latter and we suggest to supply it during the runtime by injecting it into the system properties hashmap.
Logging into the siteadmin page is also done in a nice way. Given that credentials are supplied during runtime and stored in author.login and author.password respectively, Bobcat simply adds a cookie to the browser and we’re in. No need to actually type login information or pressing the Sign In button.
Use aemLogin.authorLogin() for that.
If you find yourself in the situation where Bobcat does not have a specific helper for your task you can still use Selenium. Simply call methods on the webdriver instance variable. For example we developed a method to exclusively deal with navigation bar and switch between user modes.
Once that was done we were able to do the authoring part and immediately perform publisher side validation by switching to the Preview mode. Neat!
Authors of the Bobcat project made a good effort to provide extensive documentation of features and functionality on the Wiki page, but we still found the material to be outdated and the examples would not work right of the bat.
Cucumber: going one step further
For our test framefork implementation we used a setup of JUnit + Cucumber + Bobcat.
Cucumber is a tool for driving scenario execution and to manage reporting. Each scenario is written in the Gerkhin language. It features usage of Given, When, Then, And key words to start each phrase.
“Given I have this state, when I do something, then I should see something.”
That’s the general idea behind describing software behavior using this language. It is commonly referred to as BDD or Behaviour Driven Development. Cucumber is able to match (using a RegEx engine) each Gerkin phrase with the respective block of code (step definition) written in any major coding language and execute it.
Cucumber also supports tags. In fact this is one of its strongest features. Using tags you can include or exclude various scenarios and come up with custom run configurations based on your current needs. More on Cucumber here.
The sole purpose of using JUnit in the above setup is to kickstart Cucumber. For that we implemented this minimalistic TestRunner.java class:
Cucumber meets BDD
Personally, the main reason to use BDD is to provide across-the-team visibility for testing scenarios. With the Cucumber framework we are able to describe a user story in plain English. Now both technical and non-technical people can easily understand the test case simply by reading .feature files. It is no longer exclusively a coding expert’s role to make a list of the currently automated scenarios and compare it with acceprance criterias generated during Sprint Planning meetings. In fact the these two should match by the end of the Sprint.
Based on our experiences during client uplifts we have come to the conclusion that it is crucial for the success of the business to drive processes in each team. These processes help the team have a better understanding of the committed feature set for each sprint, as well as a methodically selected toolset. Using BDD and Bobcat framework allowed us to not only rapidly develop AEM-centric test suites for multiple teams but also provide clarity for both technical and non-technical members.
Liatrio is a DevOps Consulting firm focussing on helping enterprises get better at software delivery using DevOps & Rapid Release philosophies. We work as “boots on the ground change agents” helping our clients re-imagine their daily work and get better at delivery one day at a time. Liatrio is also hiring! If you enjoy being a part of a team that is solving challenges around software delivery automation, deployment pipelines and large scale transformations, reach out to us via our contact page on our website.