You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 15 Next »

Introduction

Here's the typical testing pyramid - it shows that UI tests will not replace any other tests (manual tests or Acceptance/Integration tests) but will complete our test setup.

The Tests

Location

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

Caution:

Caution

Some of those tests are ver< 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.

 

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 (uitest). As specifying a profile no longer invokes the default profile (jetty6-standalone) you have to pass this one as well.

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

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

 

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,jetty6-standalone

Outlook

  • Execute tests with with different browsers (Firefox, Chrome, Safari, Ie, ...) an different OS's (OSX, Unix, Windows, iOs, ...) using hudson slaves

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 delayif the test triggers a long running action (e.g. activation) this can take longer than the current timeout we use for retrieving elements...
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 WebElement.getAttribute("value") to query the input value.

 

 

  • No labels