blob: 81ee7152589b6a58989b5c0e9ea49084ca4384a6 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="generator"
content="Docutils 0.3.6: http://docutils.sourceforge.net/">
<title>Usage</title>
<link rel="stylesheet" href="default.css" type="text/css">
</head>
<body>
<div class="document" id="selenium-reference">
<div class="section" id="test-tables">
<h2><a name="test-tables">Overview</a> </h2>
This document details how Selenium can be deployed to test or script
web
applications.<br>
</div>
<div class="section" id="command-reference">
<h2><a name="test-tables">Modes of Operation</a></h2>
Broadly speaking there are two modes of operation for Selenium
TestRunner and Driven<br>
<h3>TestRunner</h3>
<img alt="standalone pic" src="images/SmallStandalone.png"
style="width: 266px; height: 113px;"><br>
<br>
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.<br>
<br>
See <a href="testrunner.html">test runner documentation</a> for more
information.<br>
<h3>Driven</h3>
<img alt="embedded pic" src="images/SmallEmbedded.png"
style="width: 248px; height: 113px;"> <br>
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. <br>
<br>
The test script is one that would be recognisable to people adept with
unit test frameworks :<br>
<br>
public void testOKClick() {<br>
selenium.verifyTitle("First Page");<br>
selenium.open("/TestPage.html");<br>
selenium.click("OKButton");<br>
selenium.verifyTitle("Another Page");<br>
}<br>
<br>
The difference from normal unit testing is that as part of the startup,
three major things have to happen:<br>
<ol>
<li>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.</li>
<li>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).</li>
<li>The test framework needs to open a browser instance and point it
to Selenium.html served in (2) above.</li>
</ol>
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.<br>
<br>
Some variations in the accesibility of the the webserver in question
for testing purposes or its scriptablity mean a more complex setup is
required:<br>
<br>
<img alt="Adjacent pic" src="images/SmallAdjacent.png"
style="width: 239px; height: 229px;"><br>
<br>
See the <a href="driven.html">driven documentation</a> for more
information.<br>
<br>
</div>
</div>
</body>
</html>
|
