Liferay QA Automation: tips & tricks

Sign up


October 18, 2018

Since I started working for Worth over a year ago, I’ve been involved in the QA process for multiple Liferay DXP projects. Because Liferay has its unique challenges for test automation, I wanted to share a few of the lessons I’ve learned.

When to automate Liferay testing

In a Liferay project, the most important thing to decide is: what can be automated? Liferay is a huge framework and is tested by Liferay itself. So the wise choice is not to test Liferay's own menus, but rather, only test the functionality your team adds.

Tool Selection

For every project, it’s important to pick the right tool for the job. Do you pick the tool you are most comfortable with? And do you have the time to set up and maintain the framework? And does the programming language play a part?

If you want to test through the UI there are a lot of options, but most of them will be based on Selenium, so it’s essentially a matter of preference. In my opinion, you should pick a tool written in the same programming language as the project, so that your automation project doesn’t add an additional language (and with that more complexity) and your team is able to review your code.

Because of this, an obvious choice will be a testing framework in Java, using TestNG or JUnit and Selenium. However, in my experience these frameworks take considerable time to set up and to maintain. For the last few months I’ve been using CodeceptJS with good results. It’s very easy to set up, offers great features and it’s written in JavaScript, so your front-enders should also be able to write their own tests.

Know Your CSS

Conventional wisdom for test automation is to look for the most unique selector of the WebElement. Most of the time, you are advised to look for the ID-attribute of the element. In Liferay however, this might not be enough for a stable test. Because IDs of Liferay elements are often not consistent. That’s why it’s good to know how to use partial CSS selectors. Take, for example, the following ID: <_com_liferay_configuration_admin_web_portlet_SystemSettingsPortlet_ddm$$assetVocabularyIds$hSVYwqd2$0$$en_GB>

There are a few things here that will get your attention. First, because the portlet-name in Liferay is included in the ID, it’s loooong. Second, it’s not consistent, so as it is, it won’t be usable for automated testing. This is where CSS selectors are able to help you. By using the attribute ‘contains’, ‘starts with’ or ‘ends with’ selectors, you can make your WebElement selector a lot shorter, e.g.: <[id*=assetVocabularyIds]>

Custom Attributes will save you from Insanity

If you look around the DOM of a Liferay site, you will notice custom Liferay attributes added for their own QA team.

Screen Shot 2018-10-15 at 15.24.36

Since I started working for Worth over a year ago, I’ve been involved in the QA process for multiple Liferay DXP projects. Because Liferay has its unique challenges for test automation, I wanted to share a few of the lessons I’ve learned.

These provide great hooks for your automated tests, and can really help you in navigating Liferay-pages. Also, instead of the IDs, these attributes will stay the same. Therefore, it’s a good idea to ask your development team to implement them in their custom portlets. This will help to keep your tests coherent, and also decrease your reliance on partial selectors.

Automating Liferay’s menus

Although I said before not to test Liferay menus and configuration pages, sometimes you have no choice. Soon after you start, you will run into the problem that Liferay is not very consistent in opening its left side navigation menu after login. That’s why it’s a good idea to always check if the menu is open before clicking. Implementing a good method to check this can save you hours of figuring out why your tests only work 50 percent of the time. This is not only the case for the side navigation, but also for all the submenus in the navigation. See below for a quick code example using WebdriverIO for use in a CodeceptJS project.

Screen Shot 2018-10-15 at 15.26.06

Liferay & SPA

All navigation and configuration menus in Liferay act like a single page application. This ensures a smooth UX experience for the user, but can cause problems when automating said menus. Especially when using a Page Object Model where you initialise all the WebElements at once you will encounter more StaleElementReferenceExceptions that you’d want in the Liferay menus. I found that the best way to counter this is to only initialise your elements when you need them.


All in all, automating Liferay projects is not that different than automating non-Liferay projects. Just be mindful when picking your tools, and ensure that your WebElements point to consistent selectors. Only initialise them when you need them. Also, don’t forget that quality assurance is not a solitary endeavour, but it works best with the entire team involved.

If you enjoyed this blog, check out this blog about our Liferay partnership.

Blijf op de hoogte