From 98215a603fb798cdb4178e49061977544aaa45b7 Mon Sep 17 00:00:00 2001 From: wei <> Date: Sat, 10 Dec 2005 11:49:29 +0000 Subject: Initial import selenium functional test framework. --- .../selenium/doc/developingdrivers.html | 134 +++++++++++++++++++++ 1 file changed, 134 insertions(+) create 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 new file mode 100644 index 00000000..4c2594d9 --- /dev/null +++ b/tests/FunctionalTests/selenium/doc/developingdrivers.html @@ -0,0 +1,134 @@ + + + + + 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