As a result you should get an empty Selenium IDE window. Notice that there is a list of test cases (with one entry 'Untitled') in this case) to the left of the table. You can make it appear by moving the resize indicator in the left.

Here's what it should look like

An empty Selenium IDE

We'll go into details about how the Olat Map file works later. Here's how to configure it in Selenium IDE

This section walks through recording the first test case with Selenium IDE

A few things Gotchas here

Make sure to play with the basics of Selenium such as Running a test, Breakpointing, Stepping, Finding a UI-Element before going forward

The start of a normal Selenium test case in OLAT could look something like this (for details refer to the Selenium in-depth chapter):

The tricky part lies in the locators: these are generally speaking XPaths into the XHtml DOM tree.

In order to achieve the goal of having tests that survive between releases, and at the same time allow structural, graphical and internal changes that effect only the DOM tree and not complete workflows, there must be a concept of having locator URLs independent from the current XPath - i.e. we need to have a Locator Abstraction Layer

Luckily Selenium already comes with a concept called 'UI-Element'. If you have Selenium IDE installed, check here for the documentation

'UI-Element' allows defining customized locator. This means that we can define an alias locator, use that in the test and hide the implementation in a OLAT-version-specific Olat Map file. This allows tests to remain stable from release to release depending on the stability of workflows! If workflows change from release to release, then obviously tests that tested based on the old workflow need to be adjusted

The Olat Map file contains a hierarchically structured list of UI-Element locators mapped to XPaths

These UI-Element locators are then used by Selenium tests and are the only locators that must be used within an Olat Selenium test (enforced by the base testclass BaseSeleneseTestCase)

The Olat map file is stored here:

$CVS/olat3ext/tests/seleniumtests/ui-map/olat-ui-map.xml

Here is an excerpt from the olat-ui-map.xml file:

		 	
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ui-map PUBLIC "olat/ui-map" "olat-ui-map.dtd">

<ui-map>
	<pageset name="dmz" description="DMZ links">
		<xpath-ui-element name="username" xpath="//input[@id='lf_login']" description="username input field"/>
		<xpath-ui-element name="password" xpath="//input[@name='lf_pass']" description="password input field"/>
		<xpath-ui-element name="login" xpath="//input[@value='Login']" description="login button"/>
	</pageset>
	<pageset name="home" description="The home page">
		<pageset name="menu" description="the left hand menu">
			<xpath-ui-element name="settings" xpath="//div[contains(@class, 'o_home')]//div[@class='b_tree']//a[text()='Settings']" description="left navigation link 'Settings'"/>
		</pageset>
	</pageset>
</ui-map>
		 	

The above map translates into the following UI-Element locators:

ui=dmz::username()
ui=dmz::password()
ui=dmz::login()
ui=home::menu_settings()

Here is a description of the steps involved in converting the olat-ui-map.xml file into user-extensions.js

Virtually all links in Olat are language dependent - therefore the Olat Map file is also language dependent. This means that the test will only succeed, if the current language is correctly set to English. For test recording this is best configured before start. For the nightly test framework, this is handled by the BaseSeleneseTestCase (the base test class)

Therefore: always switch to English before you start testing

Logging into Olat is going to be the first task that every test needs to execute. At the same time it is somewhat complicated since we have to make sure, that we're running in English mode.

To simplify all this, there is framework code that handles the login:

BaseSeleneseTestCase.olatLogin(selenium,url,username,password,language)

Note that by default we should be using 'English' as the test language since the olat-ui-map file only works with English

What this means for test recording in Selenium IDE is, that the input for the automated Selenium test classes only need the part after the login

As described in the Olat Map file section earlier, tests are only maintainable if they don't use XPaths/Id-Links directly, but use the Olat Map file with their UI-Element locator notation (ui=dmz::username()). When recording tests Selenium IDE most of the times finds corresponding mapped locators and automagically records Ui-Element locators instead of XPaths or IDs. If that's the case then everything is fine. You will surely come across non-encoded locators though - or special cases which are UI-Element locators that are parametrized. In these cases you must manually fix the locator

Here's a list of known parametrized UI-Element locators:

Therefore: always use locators that start with ui= and add it to the olat-ui-map.js if the link is not encoded yet

A Selenium test recorded in Selenium IDE can be stored in a Selenium-own format (HTML) or converted into any programing language.

Supported conversion formats in Selenium IDE

The process of converting a Selenium IDE test into a nighlty olat selenium test is as follows:

Download Selenium RC here

But note: Version 1.0 beta 1 does NOT work with Firefox 3 - therefore download the nightly version or ask the developers for the right version since nightly is very unstable at times

Start Selenium RC as follows:

Use the tutorial examples in $CVS/olat3ext/tests/seleniumtests/src/org/olat/test/tutorial as starting points.

The main idea is to have your JUnit test class extend BaseSeleneseTestCase and call the two main features:

After a test was successfully made run locally, it needs some tweaking to run nightly as well

First of all, the selenium host is no longer localhost but idmels04.uzh.ch instead. (at least for the moment)

Second, the baseTestUrl might have to be adjusted, e.g. test against nightly.uzh.ch

Finally any other setup which was dependent on having an olat instance or cluster running locally or anywhere else needs to be migrated to nightly - that would include using the Setup Framework as described later in this document

The declared goal of testing in Olat is to achieve a high degree of automatism

Any guarantee of high code quality that can be achieved in an automated way - for example in a nightly test - is very valuable. Having automated tests allows to both keep test costs low and achieve an improvement of quality over release-cycles rather than a decrease due to higher complexities etc.

This automatism is not feasible on exactly all levels of testing, but the goal is to automate where it makes sense from a effort/gain point of view