By default TestPlan will use an internal browser, such as HTMLUnit. To test in an actual browser you can however use Selenium.

Starting Selenium

Before using the --testplan flag on the command line you will need to start the selenium server. This is packaged as part of TestPlan in the bin directory. It can be started with the command:

java -jar selenium-server.jar

If you require extended selenium options then you may refer to the Selenium Remote Control↗ documentation.

Running a test

You can use the Google example to test. To specify to use Seleniume you override the value Web.SessionType on the command line as below.

testplan --selenium samples.google_lookup

If you have problems you may wish to check the Selenium FAQ↗.

A common problem is that it can't find the browser (Selenium can't). Their FAQ addresses this by indicating to specify a new launcher. In TestPlan a launcher can be specified as follows.

testplan --selenium samples.google_lookup Web.BaseURL=http://google.com/ "Web.Selenium.BrowserLauncher=*firefox /usr/lib/firefox/firefox-2-bin"

Note that you may also need to define the Web.BaseURL since that is where Selenium starts at -- though in most cases TestPlan can figure that out based on your script. This is a security issue with Selenium.

Keeping the Windows Open

During a normal test flow browser windows will be opened and closed. If you encounter a situation where your test doesn't find something on the page that you think should be there, you may wish to keep the failing browser window open to investigate yourself.

To do this add Web.Selenium.NoSessionCleanup=true to your command-line.

Using Multiple Profiles

Selenium has many options which can only be specified at start time, such as the browser profile. Browsers also have several settings which can't be changed via Selenium, thus such profiles are needed.

Usually you can just run one selenium and not have to worry about any of this. However, if you need to run with more than one profile you'll need to start multiple seleniums. TestPlan handles this by allowing you to specify on which port it connects to Selenium -- thus assuming each Selenium profile is listening on a different port.

To setup the port mapping you'll need to define an item called Web.Selenium.ProfilePortString which when a session is created will be expanded to be the port number to use.

An example can best clarify how this works. The following is in a ptest→ file you include on your command line.

# Port Mapping
Web.Selenium.ProfilePortString=Web.Selenium.Ports:%%Web.Language%%_%%Web.Country%%
Web.Selenium.Ports:de_DE=4446
Web.Selenium.Ports:fr_FR=4445
Web.Selenium.Ports:en_GB=4444

# Default settings
Web.Language=fr
Web.Country=FR

With this setup the context keys Web.Language and Web.Country are used to determine to which port to connect. If they aren't altered the settings above will take hold and TestPlan will attempt to connect to Selenium on port 4445.

Note the need to put %% since on loading the ptest→ file it will be expanded once already.

An indirect lookup was chosen to assist in debugging. If you attempt to use a profile that hasn't been defined you'll see the profile attempted, rather than the source string.