Selenium/PHP/Selenium Framework

SeleniumFramework provides a standardized way of writing Selenium tests for MediaWiki and MediaWiki extensions. The software is based on the PHPUnit unit testing framework and inherits much of PHPUnit's functionality.

Installation
SeleniumFramework has the following major dependencies:

Selenium
SeleniumFramework curently uses Selenium Remote Control (Selenium RC) (and also should use Selenium Grid in the future.)
 * Download Selenium RC from http://seleniumhq.org/download
 * Installation instructions for Selenium RC can be found at http://seleniumhq.org/docs/05_selenium_rc.html#installation

PHPunit
""
 * Install PHPUnit via PHP's command line PEAR client

Testing_Selenium
Testing_Selenium is a PHP client for the Selenium Remote Control test tool. ""
 * Install Testing_Selenium via PHP's command line PEAR client

Create a selenium_settings.ini file
The selenium_settings.ini file configures various settings for SeleniumFramework, such as the browsers that Selenium will attempt to use in testing and the base URL of the wiki to be tested.

selenium_settings.ini must be created in the root or your MediaWiki installation and should use one of the provided template files from tests/selenium. The template to use depends on the Selenium project (and, possibly, version of PHP) that you are running.


 * If you are running Selenium RC with PHP 5.2, copy tests/selenium/selenium_settings_grid.ini.php52.sample into selenium_settings.ini.

Once you have created selenium_settings.ini, you will need to customize the settings it contains. At a minimum, you will need to set the  configuration value to match the base URL of the MediaWiki instance you are testing.

Update your LocalSettings.php file
Once the preceding steps are complete, you will need to update your LocalSettings.php</tt> file to enable SeleniumFramework.

To enable SeleniumFramework, you will need to add the following code to LocalSettings.php</tt>:

""

Loading test configurations and suites
Once SeleniumFramework has been enabled, you'll need to tell it what tests to run.

To do this, you'll need to add a bit more code to LocalSettings.php</tt>.

The following examples show how to load various test suites.

""

Here's a more complex example that loads the WikiEditor test suite. Note that WikiEditor must be installed for this to work.

""

Multiple MediaWiki instances
The configuration above assumes a single wiki for everything. It is possible to have two separate wikis (one driving the tests, and one being tested). More information can be found in Selenium Configuration.

Adding a test suite
To add a Selenium test, you must first create a test suite class that extends class. Look at  SimpleSeleniumTestSuite.php</tt> for an example (which is in the tests/selenium/suites</tt> directory of the MediaWiki source.

Add test cases to the suite by implementing the  function. If you have per-suite setup and teardown code, override the  and   functions.

""

Adding individual tests
In each test file listed in, create a class that extends. Name the class after the file that contains the class, omitting the extension. For example: A file named SimpleSeleniumTestCase.php</tt> should contain class.

For each test that you wish to run, add a public function to the class. Each function name should start with. For example:.

If you have per-test setup and teardown code, override the  and   functions.

""

Examples
[SeleniumTests] testSuite[SimpleSeleniumTestSuite] = "tests/selenium/SimpleSeleniumTestSuite.php"
 * For a very basic sample test suite and test case look in tests/selenium/SimpleSeleniumTestSuite.php and tests/selenium/SimpleSeleniumTestCase.php
 * You will need the following in the selenium_settings.ini file to run these tests
 * A working example can also be found at the PagedTiffHandler extension.

Test Wiki configuration
Multiple test suites that need different wiki configurations are run against a single test wiki.

Requirements

 * The test wiki should have a default configuration. This is the state that test suites should assume for a test wiki before setUp is called.
 * Each test suite needs to tell the test wiki what configuration it needs. This may be
 * files to be included for an extension
 * global configuration variables
 * Could also be used to switch out the db and images directory.
 * (Do we need more fine grained control, like per test instead of per test suite?)


 * At the end of a test suite, the wiki needs to go back to its original default configuration.

Missing

 * Concurrent test suites point to the same wiki
 * Whether this will work to change the db and images directory for the test wiki.
 * If any extensions do custom configuration that is not an include or a global config variable.

Implementation details
Test suite: Test wiki: The following happens in WebStart.php only if a global variable $wgEnableSelenium is set.
 * The test suite's setUp makes a request to the test wiki with a request parameter whose value is the test suite name.
 * After this the test can assume that the the test wiki is configured correctly for this test suite.
 * The test suite's tearDown sends another request parameter which will tell the test wiki to do back to using the default configuration.


 * If request param setupTestSuite is set
 * set a cookie containing the test suite name
 * cookie is set to expire in 10 mins (Should this be configurable)


 * If request param clearTestSuite is set
 * clear the cookie containing the test suite name
 * If we find our testSuiteName cookie
 * Look for a global variable $wgSeleniumTestConfigs[testSuiteName]. If found, this is the test suite's function that is responsible for providing the following.
 * the test specific include files
 * the test specific globals (key value pairs)


 * $wgSeleniumTestConfigs[testSuiteName] needs to be set in LocalSettings.php. The reason this is not a done via a hook is because this configuration needs to happen before Setup.php.

Test wiki configuration example: As an example see extensions/WikiEditor/tests/selenium
 * In the case that it finds neither of the request params mentioned above nor the cookie, the Setup will proceed as usual with only the default configuration.
 * LocalSettings.php should contain
 * returns an array of include files and configuration variables needed by the extension.
 * If a cookie has been set, indicating this is part of the WikiEditorTestSuite test run, we use the configuration we get from

Architecture
These files are part of the framework:
 * tests/RunSeleniumTests.php</tt> includes test suites specified in extension directories.
 * tests/Selenium.php</tt> provides access to selenium and implements common tasks.
 * tests/selenium/SeleniumLoader.php</tt> loads all the neccessary classes for the framework.
 * tests/selenium/SeleniumTestSuite.php</tt> starts and stops selenium tests.
 * tests/selenium/SeleniumTestCase.php</tt> provides some additional assertions.
 * tests/selenium/SeleniumTestListerner.php</tt> is the interface to result logging.
 * tests/selenium/SeleniumConsoleLogger.php</tt> and  tests/selenium/SeleniumHTMLLogger.php produce the actual output.
 * SimpleSeleniumTestClass.php</tt>, SimpleSeleniumTestConfig.php</tt> and <tt>SimpleSeleniumTestSuite.php</tt> in the <tt>tests/selenium/suites</tt> directory provide examples.

The tests should be located here:
 * Tests for core should be placed in the <tt>tests/selenium</tt> folder.
 * Extensions should place their tests in <tt>extensions/EXTENSION/tests/selenium</tt>

Testing with a clean database and file state
testrunner                    wiki under test --                    --- 1.1 start selenium which in turn starts a browser to talk to the wiki under test 1.2 send request for new test with unique test id and tests that will be fired 2.1 create cookie with test id                              2.2 create temporal resources according to tests list 2.3 create test tracker with timestamp 2.4 return success code 3.1 start testsuites via selenium 3.2 send a lot of individual requests according to the tests 4.1 testrunner is identified by test id                              4.2 reconfigure database and resources according to test id                              4.3 ? Do something with memcached ? 4.4 execute request 4.5 update timestamp in test tracker 5.1 send a teardown request 6.1 execute teardown, i.e. delete all resources associated with test id                              6.2 delete test tracker 6.3 return success code 7.1 stop selenium

Test style guide
This section focuses on general test style issues specific to Selenium Framework. For general issues of Selenium test style, see the test design considerations section of the Selenium documentation.

Leave no trace

 * 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.

Avoid brittle paths
Many developers will use the Selenium IDE to draft tests. This approach allows developers to rapidly rough out tests, but may generate locators that fail when used on other platforms or that are brittle and break when exposed to trivial edge cases.

When possible, avoid absolute paths. Instead, start with an element ID and work relative to the ID.

For example, if the Selenium IDE generated a path like:  and   has an ID of , then use path

File naming conventions
The names for the test and configuration files should follow these conventions:
 * All files should have a <tt>.php</tt> extension.
 * File names for configuration files should end with <tt>Config</tt>. For example: <tt>SimpleSeleniumConfig.php</tt>
 * File names for test suite files should end with <tt>TestSuite</tt>. For example: <tt>SimpleSeleniumTestSuite.php</tt>
 * File names for test files should end with <tt>TestCase</tt>. For example: <tt>SimpleSeleniumTestCase.php</tt>

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
 * Text in Table of Contents
 * 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
 * Ways to configure the wiki for specific test suites or extensions.
 * A way to bring the database to a clean initial state before each test
 * Use the mediawiki extension to write collaborative Selenium tests

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

Error about Testing_Selenium (0.4.3 is installed from pear along with PHPUnit) not being found

 * Replace /PEAR/ by the actual path to the repository

General Tips

 * Ignore port A proxy time you out port 4444.
 * Uncomment any tests in RunSeleniumTests.php to run different test suites?

Experiences: Recent changes in handling of framework

 * PEAR PHPUnit 3.4 and PEAR Testing_Selenium: Check whether properly installed, esp. PHPUnit/Framework.php
 * Installation of selenium-rc is pretty easy:
 * Download selenium rc
 * start "java -jar selenium-server.jar"