Skip to content

Commit e75f49c

Browse files
committed
archive additional wiki articles
1 parent 4f22e8f commit e75f49c

File tree

6 files changed

+329
-1
lines changed

6 files changed

+329
-1
lines changed
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,65 @@
1+
---
2+
title: "Adding new drivers to Selenium 2 code"
3+
linkTitle: "Drivers"
4+
weight: 4
5+
description: >
6+
Instructions for how to create tests for new drivers for Selenium 2.
7+
---
8+
This documentation previously located [on the wiki](https://github.com/SeleniumHQ/selenium/wiki/Writing-New-Drivers) \
9+
10+
## Introduction
11+
12+
WebDriver has a comprehensive suite of tests that describe the expected behavior of a new implementation. We'll assume that you're implementing the driver in Java for the sake of simplicity, but you can take a look at any of the existing implementations for how we handle more complex builds or other languages once you've read this.
13+
14+
## Writing a New WebDriver Implementation
15+
16+
### Create New Top-Level Directories
17+
18+
Create a new top-level folder, parallel to "common" and "firefox", named after your browser. In this, create a "src/java" and a "test/java" directory. It should be obvious what goes where.
19+
20+
### Set Up a Test Suite
21+
22+
Copy one of the existing test suites to your test tree, and modify it for your new browser. This will probably cause you to modify the "Ignore.java" class, which is to be expected, and to add a holding class for your implementation in the source tree. You **must** include the "common" directory in order to pick up all the tests. For now, as long as nothing causes a fatal crash, leave the tests as they are.
23+
24+
Once you've added the test suite, add a "build.desc" CrazyFunBuild file in the top level of your project. Model it after the one in the "htmlunit" directory. You should then be able to run your tests from the command line using the "go" script.
25+
26+
At this point, we expect total and catastrophic failure when tests are being run.
27+
28+
### Start Implementing
29+
30+
If your browser runs out of process, it is _strongly encouraged_ to make use of the JsonWireProtocol. This will make the client-side (the APIs that users use) relatively cheap to implement, and means that you get Java, C#, Ruby and Python support for significantly less effort since you can extend the remote client.
31+
32+
## Implementation Tips
33+
34+
### Where to Start
35+
36+
As mentioned, has a suite of tests. The suggested order to make these pass is roughly:
37+
38+
1. ElementFindingTest --- needed because element location is key
39+
1. PageLoadingTest
40+
1. ChildrenFindingTest --- more finding elements
41+
1. FormHandlingTest
42+
1. FrameSwitchingTest
43+
1. ExecutingJavascriptTest
44+
1. JavascriptEnabledDriverTest
45+
46+
At this point, you'll have a reasonably complete working driver. After that, it's probably best to get the user interactions correct:
47+
48+
1. CorrectEventFiringTest
49+
1. TypingTest
50+
51+
Before spelunking into the cutting-edge stuff:
52+
53+
1. AlertsTest
54+
55+
It's not necessary to get every test working in a class before moving on. I tend to go as far down a class as I can, and then switch to the next class on the list when the going gets tough. This allows you to maintain reasonable velocity and still cover the basics.
56+
57+
### Running a Single Test
58+
59+
It's far from ideal, but the method we use is to modify the SingleTestSuite class in the common project, and then modify the module it's run from via the IDE's UI (that is, just go into the launch configuration (in IDEA) and modify the module used: don't move the file!) This class should be self-explanatory.
60+
61+
### Ignoring Tests
62+
63+
At some point you'll want to stop running tests on an ad-hoc basis and make use of a continuous build product to ensure that you're not introducing regressions. At this point, the process is to run the tests from the command line. This will generate a list of failing tests. Go through each of these tests and add or modify the "@Ignore" associated with the test. Re-run the tests. It may take a few iterations, but your build will eventually go green. Nice.
64+
65+
The build makes use of ant behind the scenes and stores logs in "build/build\_log.xml" and the test logs in "build/test\_logs"
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,87 @@
1+
---
2+
title: "Backing Selenium with WebDriver"
3+
linkTitle: "Emulations"
4+
weight: 3
5+
description: >
6+
The Java and .NET versions of Selenium 2 provided implementations of the original Selenium API
7+
---
8+
(Previously located: https://github.com/SeleniumHQ/selenium/wiki/Selenium-Emulation)
9+
10+
## Backing Selenium with WebDriver
11+
The Java and .NET versions of WebDriver provide implementations of the existing Selenium API. In Java, it is used like so:
12+
13+
```
14+
// You may use any WebDriver implementation. Firefox is used here as an example
15+
WebDriver driver = new FirefoxDriver();
16+
17+
// A "base url", used by selenium to resolve relative URLs
18+
String baseUrl = "http://www.google.com";
19+
20+
// Create the Selenium implementation
21+
Selenium selenium = new WebDriverBackedSelenium(driver, baseUrl);
22+
23+
// Perform actions with selenium
24+
selenium.open("http://www.google.com");
25+
selenium.type("name=q", "cheese");
26+
selenium.click("name=btnG");
27+
28+
// And get the underlying WebDriver implementation back. This will refer to the
29+
// same WebDriver instance as the "driver" variable above.
30+
WebDriver driverInstance = ((WebDriverBackedSelenium) selenium).getUnderlyingWebDriver();
31+
```
32+
33+
## Pros
34+
35+
* Allows for WebDriver and Selenium to live side-by-side.
36+
* Provides a simple mechanism for a managed migration from the existing Selenium API to WebDriver's.
37+
* Does not require the standalone Selenium RC server to be run
38+
39+
## Cons
40+
41+
* Does not implement every method
42+
* But we'd love feedback!
43+
* Does also emulate Selenium Core
44+
* So more advanced Selenium usage (that is, using "browserbot" or other built-in Javascript methods from Selenium Core) may need work
45+
* Some methods may be slower due to underlying implementation differences
46+
* Does not support Selenium's "user extensions" (_i.e._, user-extensions.js)
47+
48+
### Notes
49+
After creating a `WebDriverBackedSelenium` instance with a given Driver, one does not have to call `start()` - as the creation of the Driver already started the session. At the end of the test, `stop()` should be called **instead** of the Driver's `quit()` method.
50+
51+
This is more similar to WebDriver's behaviour - as creating a Driver instance starts a session, yet it has to be terminated explicitly with a call to `quit()`.
52+
53+
## Backing Selenium with RemoteWebDriver
54+
Starting with release 2.19, `WebDriverBackedSelenium` can be used from any language supported by WebDriver and Selenium.
55+
56+
For example, in Python:
57+
```
58+
driver = RemoteWebDriver(desired_capabilities = DesiredCapabilities.FIREFOX)
59+
selenium = DefaultSelenium('localhost', '4444', '*webdriver', 'http://www.google.com')
60+
selenium.start(driver = driver)
61+
```
62+
63+
Provided you keep a reference to the original WebDriver and Selenium objects you created, you can use even the two APIs interchangeably. The magic is the "`*webdriver`" browser name passed to the Selenium instance, and that you pass the WebDriver instance when calling `start()`.
64+
65+
In languages where DefaultSelenium doesn't have `start(driver)`, you can connect the WebDriver and Selenium objects together yourself, by supplying the WebDriver session ID to the Selenium object.
66+
67+
For example, in C#:
68+
```
69+
70+
RemoteWebDriver driver = new RemoteWebDriver(DesiredCapabilities.Firefox());
71+
string sessionId = (string) driver.Capabilities.GetCapability("webdriver.remote.sessionid");
72+
DefaultSelenium selenium = new DefaultSelenium("localhost", 4444, "*webdriver", "http://www.google.com");
73+
selenium.Start("webdriver.remote.sessionid=" + sessionId);
74+
```
75+
76+
## Backing WebDriver with Selenium
77+
78+
WebDriver doesn't support as many browsers as Selenium does, so in order to provide that support while still using the webdriver API, you can make use of the `SeleneseCommandExecutor` It is done like this:
79+
80+
```
81+
Capabilities capabilities = new DesiredCapabilities()
82+
capabilities.setBrowserName("safari");
83+
CommandExecutor executor = new SeleneseCommandExecutor("http:localhost:4444/", "http://www.google.com/", capabilities);
84+
WebDriver driver = new RemoteWebDriver(executor, capabilities);
85+
```
86+
87+
There are currently some major limitations with this approach, notably that `findElements` doesn't work as expected. Also, because we're using Selenium Core for the heavy lifting of driving the browser, you are limited by the Javascript sandbox.
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,35 @@
1+
---
2+
title: "WebDriver For Mobile Browsers"
3+
linkTitle: "Mobile"
4+
weight: 13
5+
description: >
6+
Describes how Selenium 2 supported Android and iOS before Appium was created
7+
---
8+
This documentation previously located [on the wiki](https://github.com/SeleniumHQ/selenium/wiki/Untrusted-SSL-Certificates)
9+
10+
## Introduction
11+
12+
We provide mobile drivers for two major mobile platforms: Android and iOS (iPhone & iPad).
13+
14+
They can be run on real devices and in an Android emulator or in the iOS Simulator, as appropriate. They are packaged as an app. The app needs to be installed on the emulator or device. The app embeds a [RemoteWebDriver server](https://github.com/SeleniumHQ/selenium/wiki/RemoteWebDriverServer) and a light-weight HTTP server which receive, and respond to, requests from WebDriver Clients i.e. from your automated tests.
15+
16+
The connection between the server on the mobile platform and your tests uses an IP connection. The connection may need to be configured. For Android you can connect establish an IP connection over USB.
17+
18+
In some cases your existing WebDriver tests may run successfully e.g. where a common web site serves mobile and desktop users and where the UI is relatively straight-forward. However in other cases you may end up needing to create specific tests for the mobile site; particularly when the site provides specific capabilities, user interfaces, etc. for mobile browsers.
19+
20+
Even when a common web site serves both desktop and mobile browsers, you may want to consider writing specific tests that incorporate factors such as the screen-size of the mobile devices, and different ways users are likely to interact with your web site or web app.
21+
22+
## Getting Started
23+
24+
[Android Setup](https://github.com/SeleniumHQ/selenium/wiki/AndroidDriver)
25+
26+
[iPhone & iPad Setup](https://github.com/SeleniumHQ/selenium/wiki/IPhoneDriver)
27+
28+
## Additional Mobile Platforms
29+
There are several related opensource projects that include support for other Mobile platforms. These include:
30+
31+
[Blackberry WebDriver](http://code.google.com/p/webdriver-blackberry/), for BlackBerry 5.0 and onward.
32+
33+
[Headless WebKit WebDriver](http://code.google.com/p/webkitdriver/). Many mobile browsers are WebKit based. Headless WebKit provides a fast light-weight solution.
34+
35+
These projects don't appear to be active, however they may provide a starting point for future work on these platforms.
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,54 @@
1+
---
2+
title: "Limitations of scaling up tests in Selenium 2"
3+
linkTitle: "Parallel Execution"
4+
weight: 11
5+
description: >
6+
Summary of additional constraints that arise when running Selenium2 in parallel.
7+
---
8+
This documentation previously located [on the wiki](https://github.com/SeleniumHQ/selenium/wiki/Scaling-WebDriver)
9+
10+
## Running parallel Selenium2
11+
12+
This page tries to summarize additional constraints that arise when running Selenium2 in parallel.
13+
14+
### WebDriver instantiation
15+
While an individual WebDriver instance cannot be shared among threads, it is easy to create multiple WebDriver instances.
16+
17+
### Ephemeral sockets
18+
There is a general problem of TCP/IP v4, where the TCP/IP stack uses ephemeral ports when making a connection between two sockets. The typical symptom of this is that connection failures start appearing after a short time of running, often a minute or two. The message will vary somewhat but it always appears after some time, and if you reduce the number of browsers it will eventually work fine.
19+
20+
[Wikipedia on Ephemeral ports](http://en.wikipedia.org/wiki/Ephemeral_port) or a quick google of "ephemeral sockets <your os name>" will tell you what your current OS delivers and how to set it.
21+
22+
Currently (2.13.0) it seems like a firefox running at full blast consumes something in the range of 2000 ephemeral ports per firefox; your mileage will vary here. This means you can
23+
run out of ephemeral port on Windows XP with as litttle as 2 browsers, maybe even 1 if you for instance iterate extermly quickly .
24+
25+
26+
#### Will it be fixed ?
27+
The solution to the ephemeral socket problem is HTTP1.1 keep alive on the connections. Firefox does not support keep-alive as of version 2.13.0.
28+
29+
#### Things that are fixed
30+
* The java client.
31+
* Selenium server ("rc").
32+
* Selenium grid hub & nodes
33+
* The ruby bindings (see notes in [RubyBindings](RubyBindings.md)).
34+
* The IE driver.
35+
* ChromeDriver
36+
37+
The means you can use the java client to scale out to remote boxes running selenium server and never have any problems on the central build server. You may need to solve socket problems on the remote boxes though.
38+
39+
#### Microsoft Windows
40+
If you are using the old versions of Windows (<=2003, inc XP) you should not be
41+
waiting for port usage to get low enough to fit in this space. That may simply never happen, although some combinations probably will. See http://support.microsoft.com/kb/196271 on how to adjust it.
42+
43+
If you for technical reasons cannot adjust the port range on your Windows machine you will not be able to run more than 2-3 firefox browsers.
44+
45+
### Avoiding the socket lock
46+
Starting new browsers between each test class/test method is slow, and the socket lock also uses Ephemeral sockets, worsening the problem described above.
47+
48+
If you're using a suite-less test setup (like many JUnit4 users), you often start/stop the browsers in @BeforeClass/@AfterClass methods. Another option is to start the browsers in @BeforeClass and use something like JUnit/TestNG run listeners to shut down all the browsers at the end of the test run. Maven surefire supports run listeners for both JUnit and TestNG.
49+
50+
(TODO: Strategies to disable the socket lock and manage the ports yourself)
51+
52+
### Native events
53+
54+
Due to a shared file in the native events logic, the firefox driver should probably not be using native events when running concurrently. (Watch [this issue](http://code.google.com/p/selenium/issues/detail?id=1326)).

website_and_docs/content/documentation/legacy/selenium_2/remote_server.en.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
---
22
title: "Remote WebDriver standalone server"
33
linkTitle: "Remote Server"
4-
weight: 6
4+
weight: 10
55
description: >
66
Working with the Standalone Server.
77
aliases: [
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,87 @@
1+
---
2+
title: "Untrusted SSL Certificates"
3+
linkTitle: "SSL Certs"
4+
weight: 12
5+
description: >
6+
Details on how Selenium 2 accepted untrusted SSL certificates
7+
---
8+
This documentation previously located [on the wiki](https://github.com/SeleniumHQ/selenium/wiki/Untrusted-SSL-Certificates)
9+
10+
## Introduction
11+
This page details how WebDriver is able to accept untrusted SSL certificates, allowing users to test trusted sites in a testing environment, where valid certificates usually do not exist. This feature is turned on by default for all supported browsers (Currently Firefox).
12+
13+
## Firefox
14+
### Outline of solution
15+
Firefox has an interface for overriding invalid certificates, called nsICertOverrideService. Implement this interface as a proxy to the original service - **unless** untrusted certificates are allowed. In that case, when asked about a certificate (a call to hasMatchingOverride for an invalid certificate) - indicate it's trusted.
16+
17+
### Implementation details
18+
Implementing the idea is mostly straightforward - badCertListener.js is a stand-alone module, that, when loaded, registers a factory for returning an instance of the service. The interesting function is hasMatchingOverride:
19+
```
20+
WdCertOverrideService.prototype.hasMatchingOverride = function(
21+
aHostName, aPort, aCert, aOverrideBits, aIsTemporary)
22+
```
23+
The aOverrideBits and aIsTemporary are output arguments. This is where things get a bit tricky:
24+
There are three possible override bits:
25+
```
26+
ERROR_UNTRUSTED: 1,
27+
ERROR_MISMATCH: 2,
28+
ERROR_TIME: 4
29+
```
30+
31+
It's impossible to just set them all, since Firefox expects a perfect match between the offences generated by the certificate and the function's return value: (security/manager/ssl/src/SSLServerCertVerification.cpp:302):
32+
33+
```
34+
if (overrideService)
35+
{
36+
PRBool haveOverride;
37+
PRBool isTemporaryOverride; // we don't care
38+
39+
nsrv = overrideService->HasMatchingOverride(hostString, port,
40+
ix509,
41+
&overrideBits,
42+
&isTemporaryOverride,
43+
&haveOverride);
44+
if (NS_SUCCEEDED(nsrv) && haveOverride)
45+
{
46+
// remove the errors that are already overriden
47+
remaining_display_errors -= overrideBits;
48+
}
49+
}
50+
51+
if (!remaining_display_errors) {
52+
// all errors are covered by override rules, so let's accept the cert
53+
return SECSuccess;
54+
}
55+
```
56+
57+
The exact mapping of violation to error code can be easily seen at security/manager/pki/resources/content/exceptionDialog.js (in Firefox source):
58+
```
59+
var flags = 0;
60+
if(gSSLStatus.isUntrusted)
61+
flags |= overrideService.ERROR_UNTRUSTED;
62+
if(gSSLStatus.isDomainMismatch)
63+
flags |= overrideService.ERROR_MISMATCH;
64+
if(gSSLStatus.isNotValidAtThisTime)
65+
flags |= overrideService.ERROR_TIME;
66+
```
67+
68+
The SSL status can be obtained from `"@mozilla.org/security/recentbadcerts;1"` usually - However, the certificate (and its status) are added to this service only **after** the call to `hasMatchingOverride`, so there is no easy way to find out the certificate's SSLStatus. Instead, the checks have to be executed manually.
69+
70+
71+
Two checks are carried out:
72+
* Calling `nsIX509Cert.verifyForUsage`
73+
* Comparing hostname against `nsIX509Cert.commonName`. If those are not equal, `ERROR_MISMATCH` is set.
74+
75+
The second check indicates whether `ERROR_MISMATCH` should be set.
76+
The first check should indicate whether `ERROR_UNTRUSTED` and `ERROR_TIME` should be set. Unfortunately, it does not work reliably when the certificate expired **and** is from an untrusted issuer. When the certificate has expired, the return code would be `CERT_EXPIRED` even if it is also untrusted. For this reason, the FirefoxDriver assumes that certificates will be untrusted - it **always** sets the `ERROR_UNTRUSTED` bit - the other two will be set only if the conditions for them are met.
77+
78+
This could pose a problem for someone testing a site with a valid certificate that does not match the host name it's served from (e.g. test environment serving production certificates). An additional feature for `FirefoxProfile` was added: `FirefoxProfile.setAssumeUntrustedCertificateIssuer`. Calling this function with `false` will turn the `ERROR_UNTRUSTED` bit off and allow a user to work in such situation.
79+
80+
## HTMLUnit
81+
Not tested yet.
82+
83+
## IE
84+
Not implemented yet.
85+
86+
## Chrome
87+
Not implemented yet.

0 commit comments

Comments
 (0)