The story starts in 2004 at ThoughtWorks in Chicago, with Jason Huggins building the Core mode as "JavaScriptTestRunner" for the testing of an internal Time and Expenses application (Python, Plone). Automatic testing of any applications is core to ThoughtWork's style, given the Agile leanings of this consultancy. He has help from Paul Gross and Jie Tina Wang. For them, this was a day job.
Over the last decade, a large ecosystem of Open Source projects have sprouted up around Selenium. This page attempts to capture some of those projects that make use of Selenium WebDriver as a central part of what they do. Selenium can be extended in different ways. Here are a number of drivers, bindings, plugins, and frameworks created and maintained by third parties.
The Selenium project is a member of the Software Freedom Conservancy, a 501(c)3 non-profit organization. The Conservancy has reduced the management overhead associated with creating our own, dedicated legal entity. The majority of sponsorship funds go directly towards supporting the Selenium project, such as server, software and conference expenses.
Selenium is certainly a team effort! There are several ways you can help out, whether you’re a programmer, designer, QA engineer, writer, project manager, or just willing to help. If you’re interested in helping, the best way to connect with us is at the Selenium Developers Group. We’ll work with you to get you set up to contribute.
If you are beginning with desktop website or mobile website test automation, then you are going to be using WebDriver APIs. WebDriver uses browser automation APIs provided by browser vendors to control browser and run tests. This is as if a real user is operating the browser. Since WebDriver does not require its API to be compiled with application code, it is not intrusive. Hence, you are testing the same application which you push live.
IDE (Integrated Development Environment) is the tool you use to develop your Selenium test cases. It’s an easy-to-use Chrome and Firefox extension and is generally the most efficient way to develop test cases. It records the users’ actions in the browser for you, using existing Selenium commands, with parameters defined by the context of that element. This is not only a time-saver but also an excellent way of learning Selenium script syntax.
Selenium Grid allows you to run test cases in different machines across different platforms. The control of triggering the test cases is on the local end, and when the test cases are triggered, they are automatically executed by the remote end. After the development of the WebDriver tests, you may face the need of running your tests on multiple browser and operating system combinations. This is where Grid comes into the picture.
This documentation previously located on the wiki. The InternetExplorerDriver is a standalone server which implements WebDriver’s wire protocol. This driver has been tested with IE 11, and on Windows 10. It might work with older versions of IE and Windows, but this is not supported. The driver supports running 32-bit and 64-bit versions of the browser. The choice of how to determine which “bit-ness” to use in launching the browser depends on which version of the IEDriverServer.exe is launched. If the 32-bit version of IEDriverServer.exe is launched, the 32-bit version of IE will be launched. Similarly, if the 64-bit version of IEDriverServer.exe is launched, the 64-bit version of IE will be launched
- The IEDriverServer executable must be downloaded and placed in your PATH.
- On IE 7 or higher on Windows Vista, Windows 7, or Windows 10, you must set the Protected Mode settings for each zone to be the same value.
The value can be on or off, as long as it is the same for every zone. To set the Protected Mode settings, choose “Internet Options…” from the Tools menu,
and click on the Security tab. For each zone, there will be a check box at the bottom of the tab labeled “Enable Protected Mode”.
- Additionally, “Enhanced Protected Mode” must be disabled for IE 10 and higher. This option is found in the Advanced tab of the Internet Options dialog.
- The browser zoom level must be set to 100% so that the native mouse events can be set to the correct coordinates.
- For Windows 10, you also need to set “Change the size of text, apps, and other items” to 100% in display settings.
- For IE 11 only, you will need to set a registry entry on the target computer so that the driver can maintain a connection to the instance of Internet
Explorer it creates. For 32-bit Windows installations, the key you must examine in the registry editor is HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet
Explorer\Main\FeatureControl\FEATURE_BFCACHE. For 64-bit Windows installations, the key is
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BFCACHE. Please note that the FEATURE_BFCACHE
subkey may or may not be present, and should be created if it is not present. Important: Inside this key, create a DWORD value named iexplore.exe
with the value of 0.
The challenge is that IE itself appears to not fully respect the Windows messages we send the IE browser window (WM\_MOUSEDOWN and WM\_MOUSEUP) if the window doesn’t have the focus. Specifically, the element being clicked on will receive a focus window around it, but the click will not be processed by the element. Arguably, we shouldn’t be sending messages at all; rather, we should be using the SendInput() API, but that API explicitly requires the window to have the focus. We have two conflicting goals with the WebDriver project. First, we strive to emulate the user as closely as possible. This means using native events rather than simulating the events using JavaScript. Second, we want to not require focus of the browser window being automated. This means that just forcing the browser window to the foreground is suboptimal. An additional consideration is the possibility of multiple IE instances running under multiple WebDriver instances, which means any such “bring the window to the foreground” solution will have to be wrapped in some sort of synchronizing construct (mutex?) within the IE driver’s C++ code. Even so, this code will still be subject to race conditions, if, for example, the user brings another window to the foreground between the driver bringing IE to the foreground and executing the native event. The discussion around the requirements of the driver and how to prioritize these two conflicting goals is ongoing. The current prevailing wisdom is to prioritize the former over the latter, and document that your machine will be unavailable for other tasks when using the IE driver. However, that decision is far from finalized, and the code to implement it is likely to be rather complicated.
When you attempt to hover over elements, and your physical mouse cursor is within the boundaries of the IE browser window, the hover will not work. More specifically, the hover will appear to work for a fraction of a second, and then the element will revert back to its previous state. The prevailing theory why this occurs is that IE is doing hit-testing of some sort during its event loop, which causes it to respond to the physical mouse position when the physical cursor is within the window bounds. The WebDriver development team has been unable to discover a workaround for this behavior of IE.
There are two places where the IE driver does not interact with elements using native events. This is in clicking option elements within a select element. Under normal circumstances, the IE driver calculates where to click based on the position and size of the element, typically as returned by the JavaScript getBoundingClientRect() method. However, for option elements, getBoundingClientRect() returns a rectangle with zero position and zero size. The IE driver handles this one scenario by using the click() Automation Atom, which essentially sets the .selected property of the element and simulates the onChange event in JavaScript. However, this means that if the onChange event of the select element contains JavaScript code that calls alert(), confirm() or prompt(), calling WebElement’s click() method will hang until the modal dialog is manually dismissed. There is no known workaround for this behavior using only WebDriver code. Similarly, there are some scenarios when submitting an HTML form via WebElement’s submit() method may have the same effect. This can happen if the driver calls the JavaScript submit() function on the form, and there is an onSubmit event handler that calls the JavaScript alert(), confirm(), or prompt() functions.