Page tree
Skip to end of metadata
Go to start of metadata

Magnolia 5.5 and above


You need the docker-engine installed on your local machine. (For macOS have a look here)


All UI-Tests are located in the bundles under either ce/magnolia-integration-tests/tests or ee/magnolia-ee-integration-tests/tests

Running the tests

Automated run

We use Selenium for testing our ui and HtmlUnit for our integration tests. The UI-Tests will are part of magnolia-integration-test/tests and use its test-webapp & test-public-webapp. UI-Tests are only triggered if you specify the corresponding maven profile ui-tests.

In short, use the following command to automatically run all UI-Tests

launch uitests
..../magnolia-integration-tests/tests mvn clean install -P ui-tests

Run all tests in a single class

launch uitests for one class
..../magnolia-integration-tests/tests mvn clean install -P ui-tests -DfailIfNoTests=false -Dit.test=MyTestClass

Run a single test case

launch uitests for one class
..../magnolia-integration-tests/tests mvn clean install -P ui-tests -DfailIfNoTests=false -Dit.test=MyTestClass#myTest

Manual run

If you want to run the ui tests manually to debug the ui-test code you could basically just run the test in our IDE. The drawback with this simple approach is that the whole environment with the web & selenium containers including magnolia installation is done with every start.

So to have a smaller footprint we first have to start just the web container with magnolia and the selenium host with the following script

launch tomcat and selenium container
$ mvn clean install
$ ./

(It's important to run install before because will take the produced webapp wars and create a docker image out of it)

Then you have to launch the test with -Dsetup.test.env=false so the test environment is not started and stopped with every test launch (thats what you have already done with

To observe the browser with the test execution launch a VNC client and connect to localhost:5901 with password "secret". (Under macOS that easily done with the app Screen Sharing)

No Docker Setup (Manual run)

If Docker performance on MacOS is questionable in your case then you would want this setup method, which is:

+ Start test webapps locally

+ Run Selenium server locally

+ Run UI tests from your IDE and monitoring test execution with local Chrome browser


Patch CE integration test setup, so that it can by-pass completely docker related calls, can be done with this patch:


Start test webapps (author and public) ensure that selenium server can communicate with them via:

 + http://localhost:8080/magnoliaAuthor

 + http://localhost:8080/magnoliaPublic

Start Selenium server (with chrome driver in the same folder)

macos:selenium user$ ls -l

total 69216

-rwxr-xr-x  1 user  staff  12012868 Mar  1  2018 chromedriver

-rw-r--r--@ 1 user  staff  23422300 Mar 16  2018 selenium-server-standalone-3.11.0.jar

macos:selenium user$ java -jar selenium-server-standalone-3.11.0.jar 

Lanch tests with additional params


-ea -Dsetup.test.env=false -DcontainerHttpPort=8080 -DprivateHostName=localhost -Dserver.public.port=8080

Here is Junit test template that applied to all new test profile.

Test will be executed in a new Chrome browser window.

Magnolia 5.4


Our ui tests are placed in the ce-bundle/magnolia-integration-tests/tests because all the required setup (install and start an author and public instance) is already there.

Running the tests


Some of those tests are very sensitive - when running them on your local machine, make sure to not do anything else while they're running. e.g. don't switch to any application or type anything. This can be enough to make some of the UI tests fail.

You need docker installed as well as both the tomcat container as well as the browser for the ui-tests are started as docker containers. (For macOS have a look here)

Automated run

We use Selenium for testing our ui. The UITest will be part of magnolia-integration-test/tests and use its test-webapp & test-public-webapp. UITests are only triggered if you specify the corresponding profile (ui-tests).

In short, use the following command to automatically run the ui tests

launch uitests
..../magnolia-integration-tests/tests mvn clean install -P ui-tests -DseleniumBrowser=chrome
Run only the tests in one class
launch uitests for one class
..../magnolia-integration-tests/tests mvn clean install -P ui-tests -DseleniumBrowser=chrome -DfailIfNoTests=false -Dit.test=MyTestClass

(Note that this will also trigger the crawling after the test, it would be nice to figure out a command that runs one class, but does not trigger the crawling.)

Run only one test
launch uitests for one test
..../magnolia-integration-tests/tests mvn clean install -P ui-tests -DseleniumBrowser=chrome -DfailIfNoTests=false -Dit.test=MyTestClass#myTest

Manual run

If you want to run the ui tests manually from within your IDE you can start the author and public tests instance with

launch uitests
..../magnolia-integration-tests/tests mvn clean install -P manual-tests

Once this is running, then you can simply run or debug with JUnit in your IDE as you would a normal unit test.


  • Execute tests with different browsers (Firefox, Chrome, Safari, Ie, ...) an different OS's (OSX, Unix, Windows, iOs, ...) simulating different devices (e.g. ipad as well).

Implementation hints

Our UI tests are implemented with selenium. Despite the fact that this tool is really mature, those tests aren't as reproducible as ordinary unit-tests. Here's a list of hints that should help to write stable magnolia ui tests:

IssuePotential fixRemark
Element cannot be found although it's thereadd a delay Fix your xpath, or use one of the waitUntil methods.querying for an element (AbstractMagnoliaUITest#getElementByPath(By)) will explicitly try for 5 seconds - if the test triggers a long running action (e.g. activation) this can take even longer so we might have to add an additional, explicit delay
Element is found although it should be goneadd a delay Fix your xpath, or use one of the waitUntil methods.unlike in the case where we check for existence of an element we don't have any implicit or explicit delay here - if the element needs some time to go away (e.g. Overlay fadeout) we have to add an explicit delay. use waitUntil(elementIsGone()
Input field value cannot be queried with xpathdont use xpathinput[@class = 'classname' and @value = 'form input...'] could be changed to input[@class = 'classname] and use a condition like waitUntil(attributeToBe(locator, "value", "form input...")) to query the input value.
Form validation fails, even if fields are properly enteredensure blur / changeafter filling an input with sendKeys, one should explicitly blur the field - i.e. click anywhere else - and allow some time for the change event to occur. Only then, pressing 'save changes' will be properly aware of the modifications.
Getting another element instead of the expected onescope XPath queriesmaking dead simple queries like //input[@class='v-textfield'] should be carefully considered, there may be more elements of same kind (inputs, buttons) currently loaded in the UI. Try to scope selectors at least to subApp level.
Querying for descendent elementsuse .// XPath prefixinvoking parent.findElement(By.xpath("//something")) doesn't query only for sub-elements of parent. To evaluate an XPath expression relative to parent WebElement, one needs to use the .// prefix instead.

If you find it hard to create XPath queries, you might find the following helpful:

  1. Firefox console can evaluate XPath expressions, through the $x() function
  2. Firebug + FirePath (depending on Firebug), which makes it easy to test xpath statements
  3. Firefox XPath Checker extension
If writing an XPath for the element you're looking is hard, XPath should probably not be used for this case.

Screenshots of each stage of the test

Our framework is rigged to generate a screenshot and save it during the test - this can help debug what went wrong with the test. These images are stored in tests/target/surefire-reports/

Even on hudson you can access these screenshots:

  • No labels


  1. Hi,

    One of the recurrent requests I have from clients is to provide a test framework and a test pack (our functional tests). They usually run such test pack and build their own tests on top of the same test framework. It brings a lot of value in term of non-regression testing when upgrading to a new Magnolia version.

    Do you have such plans regarding testing? How mature this test framework is currently?

  2. We use it for all major branches and for all releases. However the tests we have are there to cover basic functionality. While anyone should be able to use the framework and run it against their instance, they are on their own to write those tests for apps or other functions they develop themselves.

    Plus there might be some requests to make it more configurable in regard of ports or app servers used for testing if customers start using it actively ... but until they do, we have no way of knowing what are the bottlenecks.

  3. I think Nicolas' request makes sense; one could want to execute our base tests on their own instance, so as to validate their install / config. (not saying that our current tests would be appropriate). And perhaps more importantly, they probably want/need a base infrastructure to add their own tests. There's been talk of extracting/reworking our framework, but no timeline.