Selenium/PHP/Selenium Framework

Purpose
SeleniumFramework provides a standardised way of writing Selenium tests for MediaWiki and its extensions. It is based on PHPUnit tests.

Set up the environment
In order to work properly, the framework builds on some external dependencies:
 * You need to set up a Selenium server, either Selenium RC or Selenium Grid
 * The PEAR PHPUnit 3.4 library must be accessible within your PHP path
 * Also, PEAR Testing_Selenium must be accessible within your PHP path

Configure the framework
Next, you have to tell the framework about your environment. This should be done in a file called LocalSeleniumSettings.php in maintenance/tests. These options are currently available:

Writing tests
In order to add a Selenium test, you have to create a test file. This should add a Selenium test suite and includes the actual tests. Here is a simple example which types some text in an article, saves the article and checks whether the text is still present:

As of now, you have to manually add the test file to maintenance/tests/RunSeleniumTests.php. This will be replaced by a command line argument in the future.

Running the tests
In order to run the tests from a console, you just need to execute the test runner in a commandline:

php RunSeleniumTests.php

Working example
A working example can be found at the PagedTiffHandler extension.

Architecture
These files are part of the framework:
 * RunSeleniumTests.php includes test suites specified in extension directories.
 * LocalSeleniumSettings.php is the local configuration file.
 * selenium/Selenium.php provides access to selenium and implements common tasks.
 * selenium/SeleniumTestSuite.php starts and stops selenium tests.
 * selenium/SeleniumTestCase.php provides some additional assertions.
 * selenium/SeleniumTestListerner.php is the interface to result logging.
 * selenium/SeleniumConsoleLogger.php and SeleniumHTMLLogger.php produce the actual output.
 * Individual tests are located with the extensions in the directory selenium.

Test styleguides

 * A test should leave at best no traces in the wiki.
 * If this is not possible, the test should leave the wiki in a state which allows the test to be re-run.

Add common test tasks
Please add to this list...
 * Trigger user preferences
 * Edit a page (initial support already implemented)
 * Upload images (already in PagedTiffHandler tests)
 * Show edit and history mode
 * Revert pages

Add common assertions
Please add to this list
 * Text within an article
 * Text in Headlines
 * Error messages

Improvements

 * Make test result logging more talkative
 * Check prerequisites of MediaWiki configuration (initial support in PagedTiffHandler tests)
 * Find a way to execute selenes recorded via Selenium IDE
 * Refactor naming conventions

Further ideas
A test (or a single test suite) should be able to reconfigure the wiki according to its needs. Here, some serious security issues arise. This might be a possible way: If the hook is not triggered in LocalSettings, no reconfiguration can take place.
 * Add a hook 'LocalSettingsEnd' at the end of LocalSettings.php
 * Add some URL parameter which indicates which test is being run
 * Within the extension, the hook code now changes the configuration