Skip to main content

Selenium Web Driver Hierarchy

 

Extends

WebDriver Extents Search Context

Firefox Extends Remote WebDriver

IE Driver Extends Remote WebDriver

Safari Extends Remote WebDriver

Chromium Extends Remote WebDriver

Reason

Common Interface – Certain browsers inherits the common behaviours from Remote WebDriver, these common interfaces allow the developers and tester to perform their operation such as commands and methods across different browsers.

Code Reusability: -By leveraging the capabilities provided by Remote web Driver, the browser specific driver can reuse the common functionality for communication with selenium WebDriver and browser.

Consistent Architecture-Helps this architecture to compatible with different browsers, consistency simplifies the design of the selenium WebDriver framework.

Remote Execution- t allows users to run their tests on a remote machine (e.g., on a Selenium Grid) by providing a central hub for test execution.

Edge and Chromium Extends Chromium Driver.

Reason

 The Chrome and Edge rooted from Chromium WebDriver desire for common and reusable codebase,

 

Implements

Remote Web Driver Implements the JavaScript Executor, WebDriver, Take Screenshot  

Reason -Remote WebDriver has multiple Interfaces and including JavaScript Executor, WebDriver, Take Screenshot  

WebDriver – Primary interface that defines set of methods interacts with browsers, used as a generic WebDriver, and control all instances regardless of remote or local.

JavaScript- Implementing JavaScript Executor allows Remote Web Driver to execute JavaScript commands, providing additional flexibility for advanced interactions and manipulations that may not be achievable through standard WebDriver commands.

Takes Screenshot Interface: which is a valuable feature for debugging, reporting, and capturing visual evidence during test execution.

RemoteWebDriver provides additional functionality and interfaces to support various features. Some of the notable interfaces and functionalities implemented by Remote WebDriver include:

 

  1. Capabilities:
    • The Capabilities interface represents a set of key-value pairs describing the desired capabilities of a browser.
    • Remote WebDriver provides methods to set and retrieve capabilities, allowing users to configure and customize the behavior of the remote browser.
  2. HasInputDevices:
    • The HasInputDevices interface provides methods for interacting with input devices such as the keyboard and mouse.
    • Remote WebDriver implements this interface, allowing users to perform keyboard and mouse actions on the remote browser.
  3. Has Touchscreen:
    • The Has Touchscreen interface provides methods for interacting with touch-enabled devices.
    • Remote WebDriver implements this interface to support touch interactions when working with touch-enabled browsers or devices.
  4. Has Capabilities:
    • The Has Capabilities interface allows retrieving the capabilities of a WebDriver instance.
    • Remote WebDriver implements this interface, providing a way to obtain the capabilities of the remote browser.
  5. Location Context:
    • The Location Context interface represents an object that has a location on the screen.
    • Remote WebDriver implements this interface, allowing users to retrieve the location of the browser window.
  6. Application Cache:
    • The Application Cache interface provides methods to interact with the browser's application cache.
    • Remote WebDriver implements this interface to support interactions with the application cache.
  7. SessionIdProvider:
    • The SessionIdProvider interface allows retrieving the session ID associated with a WebDriver instance.
    • RemoteWebDriver implements this interface, providing access to the unique session ID of the remote browser session.
  8. Network Connection:
    • The Network Connection interface provides methods for controlling network connections.
    • Remote WebDriver implements this interface, allowing users to simulate different network conditions during testing.

 

Comments

Popular posts from this blog

A Well Comprehensive Test plan for Manual Testing

  Scope Definition: Define the scope based on specifications and requirements provided. However, also include exploratory testing to uncover issues that might not be explicitly mentioned in the requirements. Consider factors like usability, accessibility, security, and performance to broaden the scope beyond just functional testing. Considering factors like usability, accessibility, and security in the scope definition is essential for ensuring a comprehensive testing approach that goes beyond functional requirements Test Case Design: Use a combination of traditional methods like boundary value analysis, equivalence partitioning, and decision tables for structured testing. Incorporate exploratory testing techniques to explore the application and identify unexpected behaviour or edge cases. Prioritize test cases based on risk assessment and criticality. can implement the shift-left approach in...

Essential of Creating Test plan in Testing

  Why Test Plan is Vital Document! Test Planning process and plan itself serve as vehicle for communicating with other members of the project team, tester, Dev, BA, Peer and other stakeholders. This communication allows the test plan to influence the project team and allows the project team to influence the test plan. We can accomplish this Communication through circulation of one or more test plan drafts and through review meeting. E.g.: Please tell me what the plan is for releasing the test items into the test lab for each cycle of test execution E.g.: Please let me know which version of the test tool   will be used for the regression tests of the previous increment. A test plan Document becomes the record of previous discussions and agreements. Test Plan helps us to Manage the change if you are in Agile , have to this as Handy. Ways to write a Test Plan Document. Analyze the Product: Understand the product's objectives, target users, specific...

How test steps and Expected result and actual result should get differ each other and be unique?

  Test steps are action-oriented and describe the registration process, the expected result outlines the desired outcomes, and the actual result provides observations on what actually occurred during the execution of the test case.   Each section serves a unique purpose and together forms a comprehensive test case.  Any discrepancies between the expected and actual results can be easily identified and addressed . Test steps, expected results, and actual results in test cases should be distinct and unique to provide clarity, avoid ambiguity, and facilitate effective communication between testers and other stakeholders. Here are some guidelines on how to make them differ and unique: Test Steps: 1. Sequential and Clear: • Test steps should be listed in a sequential and clear manner.  • Each step should represent a specific action that the tester needs to perform. 2. Action-Oriented: • Use action-oriented language in test steps.  • Clearly state what actions ...