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

This page probably is outdated partially.

For a more up-to-date documentation regarding UI tests for Magnolia 6.1 and higher, please also check the documentation on bitbucket.

UI tests typically require browser/machine focus (especially when entering text in input fields). To avoid being stuck while UI tests proceed, it's handy to run them — the Selenium part — inside a VM.


  • The Magnolia webapp runs on the host as usual
    • with manual-tests profile
    • e.g.  mvn clean verify -P jetty9-standalone,manual-tests
    • free hint #1: run this build from another location on your machine than the one you typically work at
    • free hint #2: run it in offline mode (mvn -o ...) if you just installed one of the modules you want to put under test 
  • A Selenium standalone server runs on the guest VM
  • Test execution is done from the IDE, i.e. also on the host


1a. VM Setup manually

  1. Setup your VM and install Ubuntu for example
    1. mount iso image in optical drive
  2. In VirtualBox File > Host Network Manager..., click the add icon
    • creates a new virtual network interface e.g. vboxnet0 
    • (used to be Preferences > Network in former vbox versions, as illustrated below)
  3. In VM Settings > Network
    • 1st slot: select "Host-only Adapter", then choose the one you just created — that vboxnet0
    • 2nd slot: select NAT as is usually the default (to access the interwebs through the host)
  4. Install guest additions
    • When VirtualBox VM is running
    • Devices > Insert Guest Additions CD image...

1b. VM Setup with Vagrant

  1. Download and install vagrant from or use the vagrant manager
  2. Clone the repro
  3. Go to the cloned directory and run vagrant up
  4. Start selenium server with ./

2. Selenium server setup

  1. In the VM, download Selenium Server (formerly the Selenium RC Server)
  2. On your host run the UI Tests with the variables seleniumServerHostName which is the address of your newly created VM and containerHostName which is the address used of your VM to access your host system (this is probably not equal to your machines address in the magnolia network)

    $ mvn -U clean install -Pjetty9-standalone,ui-tests -DseleniumServerHostName= -DcontainerHostName=

    If necessary replace the IP addresses.

  3. In your run configuration in IntelliJ you have to add these two variables seleniumServerHostName and containerHostName as well.

3. Fancy shell script + desktop launcher for the Selenium server

  1. Create a new script, e.g. selenium-server on the desktop as follows
    • (provided your selenium server jar is on the desktop too)
      gnome-terminal -e "java -jar selenium-server-standalone-2.42.2.jar"
  2. Make it executable
    • chmod +x your-script
    • Go to Nautilus (eq. Finder) preferences
      • Edit > Preferences, "Behavior" tab
      • Tick "Run executable text files when they are opened"

  3. The fancy icon
    • Select your script, right-click and go to the file Properties >  Click the icon and select yours

Double-click your script and you're good to go! (smile)

Tips for simulating low-end hardware (like on Jenkins test runs)

When tests seem to fail randomly in a non-reproducible manner on from Jenkins, it's sometimes related to slower hardware compared to local execution. To be more consistent and robust, it can be helpful to mimic such a low-end environment.

Use low screen resolution

Some failures (like hidden dialog commit buttons) only occur on screens with low resolution. With VirtualBox guest extensions properly installed, you should be able to simply resize the VM window and the guest's virtual screen should automatically adjust. As a reference for size, screenshots from failed Jenkins build may be used; or just roughly 1000 x 700 px.

Throttle Magnolia

Other test failures are caused by racing conditions only surfacing on slow systems, where certain elements take longer to load than usual. For Linux (now OS X too), there's a command line tool called cpulimit to set an upper CPU time percentage limit for certain processes.

Setting the limit to 5% for the process with id 1234 is done by

cpulimit -l 5 -i 1234
  • No labels


  1. This is awesome. 

    The changes to AbstractMagnoliaUITest can probably be factored out and somewhat driven through a Maven profile or property (-D...), which is something we'll want to consider sooner or later to run the tests on different browsers anyway.

    Good job! 

    1. Indeed, I haven't thought much about it, but I'm all in for maven properties to specify local server and selenium server, would spare me 3 or 4 stashes :3

  2. Nice! Have you considered using a headless browser such as phantomJS? There is a Webdriver for Selenium called GhostDriver.

    1. In my case I still like to check execution for some selected test in a visual way (big grin) helps spotting where we have long timeouts before the tests proceed.

      That said you can setup whichever browser supports RemoteWebDriver in your VM and use it through the DesiredCapabilities.

  3. There should only be one limitation about this: info.magnolia.integrationtests.uitest.SeleniumProfileTestingUITest#testDefaultFirefoxDownloadSettings() will fail as the browser will download a file to the VM whereas the test will try to find the downloaded file on the host machine.

    Otherwise, it works like a charm: even got the automatic tests to run fully (except above test)...

    1. That's what I'd refer to as a self test. It'd thus be part of the tests-of-the test framework, and not executed with every (variation of) bundle tests. TOTF could have other tests that validate browser-specific stuff, as long as those browsers are somewhat available to where the tests are run. And if not, the alternative is to make those tests @PreCondition tests (annotation mine, don't even know if it exists out of the box), i.e tests that validate all-other-tests can be run in the current environment. This particular @Precondition test would then only execute if we're using firefox for the other tests, obv.