Broadly speaking there are two modes of operation for Selenium
TestRunner and Driven
TestRunner
The TestRunner mode of operation for Selenium is where its HTML &
Javascript
and the test suite are deployed alongside the Application Under Test
(AUT) on a arbitrary web server. The test suite is coded as tables in a
HTML page for each test.
See
test runner documentation for more
information.
Driven
Driven Selenium is where the browser is under the the control of a
process on the same machine. That process is either a Java, .Net, Ruby
or Python
application and it is typically run in conjunction with a unit testing
framework like JUnit or NUnit. Also possible, is a console application
driving a browser interactively.
The test script is one that would be recognisable to people adept with
unit test frameworks :
public void testOKClick() {
selenium.verifyTitle("First Page");
selenium.open("/TestPage.html");
selenium.click("OKButton");
selenium.verifyTitle("Another Page");
}
The difference from normal unit testing is that as part of the startup,
three major things have to happen:
- The test framework needs to publish a fresh copy of the AUT.
Selenium prefers to mount its own web server temporarily for the
purposes of testing.
- The test framework needs to publish the static Selenium's HTML
pages and Javascript in an apparent directory
on the same web server as (1).
- The test framework needs to open a browser instance and point it
to Selenium.html served in (2) above.
As each of these is a fairly time consuming operation, it is best that
all three of those happen in a one-time setup mode. As such, and
even though these leverage a unit testing framework, this is definately
for acceptance or functional rather than unit-testing.
Some variations in the accesibility of the the webserver in question
for testing purposes or its scriptablity mean a more complex setup is
required:
See the
driven documentation for more
information.