From 0f3a577bed4d828472469675e90fcab032e33f44 Mon Sep 17 00:00:00 2001 From: xue <> Date: Fri, 2 Jun 2006 18:27:02 +0000 Subject: merge from 3.0 branch till 1133. --- .../selenium/doc/developingdrivers.html | 134 --------------------- 1 file changed, 134 deletions(-) delete mode 100644 tests/FunctionalTests/selenium/doc/developingdrivers.html (limited to 'tests/FunctionalTests/selenium/doc/developingdrivers.html') diff --git a/tests/FunctionalTests/selenium/doc/developingdrivers.html b/tests/FunctionalTests/selenium/doc/developingdrivers.html deleted file mode 100644 index 4c2594d9..00000000 --- a/tests/FunctionalTests/selenium/doc/developingdrivers.html +++ /dev/null @@ -1,134 +0,0 @@ - - - - - Developing Drivers - - -

Overview

-This page details important information for people developing drivers -for Selenium.
-

Same Origin Policy

-This is a security issue that affects all modern browsers. It is well -described here, -but for our purposes, it constrains the way that a -JavaScript in a browser may interoperate with other open frames and -windows. In short, the Selenium JavaScript app must come from (or -appear to) the same origin as the AUT.
-

The Driver

-The driver has a number of duties. These are typically..
- -

Local, Remote and URLs
-

-An application may be testable in a remote location by humans, but for -scripted testing and the need for the driver to dynamically drive the -browser, it is optimal for the driver to be on the same machine as that -serving the AUT and the browser testing it. 
-
-Thus, an application as deployed ...
-
-http://localhost:8080/
-
-... would appear like so for the purposes of testing ...
-
-http://localhost:8080/
-
-As with the standalone version of Selenium, there are a number of files -(HTML and JavaScript) that comprise the bulk of the testing framework -and sit in the browser as testing occurs. It makes most sense to put -these in a virtual directory on the same server ...
-
-http://localhost:8080/selenium/
-
-The dynamic webapp needs to be similarly mounted ...
-
-http://localhost:8080/selenium/driver?...
-
-As the dynamic is the link between what is happening in the browser and -the driving process, it we need to somehow have an instance reference -to it.  This is easier in some languages and web servers than -others.  Also full programatic start/stop control over the web -server is not always possible for some larger web servers -implementations.
-

Reply/Request Architecture

-Because a browser cannot open a socket and listen on it, we must -effectively initiate communication thru the driver on the browser side. -Ignoring the possibilities granted by keep-alive, we simply poll from -the browser to the server and pick up commands to process inside the -browser.  Results of commands are also passed back to the dynamic -hander over the same mechanism. These are in fact done in the same HTTP -request.  The results from the previous -command go back as query string parameters, and the next command is communicated in a -text/plain document
-
-The previous/next business introduces some complexity on the driver -side of the design. Namely hidden behind the API, the driver must -manage queues for the outgoing commands and the (some time later) -incoming responses.  Java, until 1.5, did not have a blocking -queue to make this easy. Most other languages did.
-

Selenese

- - - - - - - -
Selenese is the contrived (and mostly hidden) wire language -that the -driver uses to speak to the browser-bot through the dynamic -handler. It uses HTTP for its transport, and is quite -simple.
-
-Responses come from the browser to the driver in a query -string like  
-
-  commandResult=OK,
-
-Commands go from the driver to the -browser-bot in a text/plain document:
-
-  | open | /foo/bar.html | |
-
-This two way communication is of course invisible to the observer.		The -BrowserBot, by understanding Selenese, allows a process other than the -browser itsself to direct events on the Application Under Test. 
-
-The Selenese language is simple enough to be commandable by any -language that has an API that can handle HTTP requests.
-
-Thus, Selenese allows many different open, free or closed license -drivers to interoperate with the BrowserBot.
-

Choregraphy

-The driver cleary has some fairly heavy things to do.  It is -important for some robustness to be built into the design. For example -it may take a long time for the browser to be instantiated on a -particular platform.  It is appropriate for wait timeouts to be -generous here.  Similarly whilst issuing individual commands it is -important for the driver to wait a sufficient amount of time for a -command to execute (and its result to come back).  For the most -part on a localhost setup, it will be because the AUT is slow, but it -could be because some break in the app means that there will be no -subsequent response.  Some timeout regime should be able to -recover from, mark a test as failed (for reasons of timeout), and start -again with the next test.
-
-
- - -- cgit v1.2.3