How can you choose the best cross-browser testing tool for your needs? We’ll review the challenges of cross-browser testing and consider some leading cross-browser testing solutions.

Nowadays, testing a website or an app using one single browser or device will lead to disastrous consequences, and testing the same website or app on multiple browsers using ONLY the traditional functional testing approach may lead to production issues and lots of visual bugs. 

Combinations of browsers, devices, viewports, and screen orientations (portrait or landscape) can reach the thousands. Performing manual testing on this vast amount of possibilities is no longer feasible, same as just running the usual functional testing scripts hoping to cover the most critical aspects, regions, or functionalities of our sites. 

In this article, we are going to focus on the challenges and leading solutions for cross-browser testing. 

The Challenges of Cross Browser Testing 

What is Cross Browser Testing?

Cross-browser testing makes sure that your web apps work across different web browsers and devices. Usually, you want to cover the most popular browser configurations or the ones specified as supported browsers/devices based on your organization’s products and services.

Why Do We Need Cross Browser Testing?

Basically because rendering is different and modern web apps have responsive design, but you also have to consider that each web browser handles JavaScript differently, and each browser may render things differently based on different viewports or device screen sizes. These rendering differences can result in costly bugs and negative user experience.

Challenges of Cross Browser Testing Today

Cross-browser testing has been around for quite some time now. Traditionally, testers run multiple tests and test in parallel on different browsers and this is fine, from a functional point of view. 

Today, we know for a fact that running only these kinds of traditional functional tests across a set of browsers does not guarantee your website or app’s integrity. But let’s define and understand the difference between Traditional Functional Testing and Visual Testing. Traditional functional testing is a type of software testing where the basic functionalities of an app are tested against a set of specifications. On the other hand, Visual Testing allows you to test for visual bugs, which are extremely difficult to uncover with the traditional functional testing approach.

As mentioned, traditional functional testing on its own will not capture the visual testing aspect and could lead to lack of coverage. You have to take into consideration the possibility of visual bugs, regardless of the amount of elements you actually test. Even if you tested all of them, you may encounter visual bugs that could lead to false negatives, which means, your testing was done, your tests passed and you did not capture the bug. 

Today we have mobile and IoT device proliferation, complex responsive design viewport requirements, and dynamic content. Since rendering the UI is subjective, the majority of cross-browser defects are visual.

To handle all these possibilities or scenarios, you need a tool or framework that not only runs tests but provides reliable feedback – and not just false positives or tests pending to be approved or rejected. 

When it comes to cross-browser testing, you have several options, same as for visual testing. In this article, we will explore some of the most popular cross-browser testing tools. 

Cross-Browser Testing with Your Own In-House Selenium Grid 

If you have the resources, time, and knowledge, you can spin up your own Selenium Grid and do some cross-browser testing. This may be useful based on your project size and approach.

As mentioned, if you understand the components and steps to accomplish this, go for it! 

Now, be aware, to maintain a home-grown Selenium grid cluster is not an easy task. You may find some difficulties or issues when running and maintaining hundreds of browser/nodes. Because of this, most companies end up outsourcing this tasks to vendors like Browserstack or LambdaTest, in order to save time and energy and bring more stability to their Selenium Grid infrastructure. 

Most of these vendors are really expensive, which means that you will need to have a dedicated project budget just for running your UI tests on their cloud. Not to mention the packages or plans you’ll have to acquire to run a decent amount of parallel tests.  

Considerations when Choosing Selenium Grid Solutions

When it comes to cross-browser testing and visual testing, you could use any of the available tools or frameworks, for instance LambdaTest or BrowserStack. But how can we choose? Which one is better? Are they all offering the same thing? 

Before choosing any Selenium Grid solutions, there are some key inherit issues that we must take into consideration:

1. With a Selenium Grid Solution, you need to run each test multiple times on each and every browser/device that you would like to cover, resulting in much higher maintenance (if your tests fails 5% of the times, and you now need to run the test 10 times on 10 different environments, you are adding much more failures/maintenance overhead). 

2. Cloud-based Selenium Grid solutions require constant connections between the machine inside your network that is running the test to the browser in the cloud for the entire test execution time. Many grid solutions have reliability issues around that causing environment/connection failure on some tests, and when executing tests at scale this results in some additional failures that the team needs to analyze.

3. If you try to use cloud-based Selenium Grid solutions to test an internal application, you would need to setup a tunnel from the cloud grid to your company’s network, which creates a security risk and adds additional performance/reliability issues.
4. Another critical factor for traditional “WebDriver-as-a-Service” platforms is speed. Tests could take 2-4x as much time to complete on those platforms compared to running them on local machines. 

Cross-Browser Testing with Applitools Ultrafast Grid

Applitools Ultrafast Grid is the next generation of cross-browser testing. With the Ultrafast Grid, you can run functional and visual tests once, and it instantly renders all screens across all combinations of browsers, devices, and viewports. 

Visual AI is a technology that improves snapshot comparisons. It goes deeper than pixel-to-pixel comparisons to identify changes that would be meaningful to the human eye.

Visual snapshots provide a much more robust, comprehensive, and simpler mechanism for automating verifications. Instead of writing hundreds of lines of assertions with locators, you can write a single-line snapshot capture using Applitools Eyes.

When you compound that stability with the modern cross-platform testing technology of the Ultrafast Test Grid that stability multiplies. This improved efficiency guarantees delivery of high-quality apps, on-time and without the need of multiple suites or test scripts.

Think and analyze the time that it currently takes to complete a full testing cycle on your end using traditional cross-browser testing solutions. Going from installing, writing, running, analyzing, reporting and maintaining your tests. Engineers now have the Ultrafast Grid and Visual AI technology that can be easily set on your framework, and that is also capable of testing large, modern apps across multiple environments in just minutes. 

Traditional cross-browser testing solutions that offer visual testing, are usually providing this as a separate feature or add-on that you have to pay for. What this feature does is basically taking screenshots for you to compare with other screenshots previously taken. So you can just imagine the amount of time that will take to accept or reject all these tests, and take into account that most of them will not necessarily bring useful intel, as the website or app may not change from one day to another. 

The Ultrafast Grid goes beyond simple screenshots. Applitools SDKs uploads DOM snapshots, not screenshots, to the Ultrafast Grid. Snapshots include all the resources to render a page (HTML, CSS …) and are much smaller than screenshots, so they are basically uploaded faster. 

To learn more about the Ultrafast Grid functionality and configuration, take a look at this article > https://applitools.com/docs/topics/overview/using-the-ultrafast-grid.html

Benefits and Differences when using the Applitools Ultrafast Grid

Here are some of the benefits and differences you’ll find when using this framework:

1. The Ultrafast Grid uses containers to render web pages on different browsers in a much faster and more reliable way, maximizing speed.

2. The Ultrafast Grid does not always upload a snapshot for every page. If a page’s resources didn’t change, Ultrafast Grid doesn’t upload them again. Since most page resources don’t change from one test run to another, there’s less to transfer, and upload times are measured in milliseconds.

3. As mentioned above, with Applitools Ultrafast Grid, you only need to run the test once and you’ll get the results from all browsers/devices. Now that most browsers are W3C compliant, the chances of facing functional differences between different browsers (e.g. a button clicks on one browser and doesn’t click on other browsers) are negligible, so it’s sufficient to run the functional tests just once and this will still find the common browser compatibility issues like rendering/visual differences between browsers.

4. You can use one algorithm on top of the other. Other solutions only offer the possibility of setting a level of comparison based on three modes, either Strict, Suggested (Normal) or Relax, and this is useful to some extent. But what happens if you need to select a certain region of the page to use a different comparison algorithm? Well, this is possible using the Applitools Region Types feature:

5. All of the above occurs on multiple browsers and devices combination at the same time. This is possible using the Ultrafast Grid configuration. For more information check out this article > https://applitools.com/docs/topics/sdk/vg-configuration.html

6. Applitools offers a Free version that allows you to use mostly all the Framework features, This is really cool and helpful, as you will be able to explore and use high level features like Visual AI, cross-browser testing & visual testing without having to worry about the minutes left on your free trial, as with other solutions. 

7. One of the unique and cool features of Applitools is the power of the automated maintenance capabilities that prevent the need to approve or reject the same change across different screens/devices. This reduces the overhead involved with managing baselines from different browsers and device configurations.  

Final Thoughts

Selenium Grid Solutions are everywhere, and the price varies between vendors and features. IF you have infinite time, infinite resources and infinite budget, it would be ideal to run all the tests on all the browsers and analyze the results on every code change/build. But for a company trying to optimize their velocity and run tests on every pull request/build, the Applitools Ultrafast Grid provides a compelling balance between performance, stability, cost and risk.

The post Comparing Cross Browser Testing Tools: Selenium Grid vs Applitools Ultrafast Grid appeared first on Automated Visual Testing | Applitools.

Update 10/14: Selenium 4 has been officially released! Check out our post covering everything new in the latest release right here.

A release candidate for Selenium 4 is finally here! That means we’re getting really close to the official version ?. This is a really great time to familiarize yourself with the latest Selenium features that are coming in the new release.

I’ve compiled a list of resources to help you do so. Check it out below ?.

What’s New in Selenium 4

For a quick summary of the latest Selenium 4 updates, Manoj Kumar & Anand Bagmar have you covered! Check out What’s New in Selenium 4.

Test Driving Selenium 4 with Angie Jones

If you’d like to see Selenium 4 features in action, I made this video demonstrating real examples. Check out this video of Selenium 4 features.

Selenium 4 FAQs

There were lots of questions from the audience when I recorded that video ?. Check out this followup blog post to read the answers to the most frequently asked questions about Selenium 4 features.

How to Install Selenium 4

OK, now that you know what’s new, are you ready to try it out for yourself? Great! Shama Ugale covers how to install Selenium 4 in this tutorial.

Migrating to Selenium 4: Here’s What Has Changed

Or if you just need to migrate from an Selenium 3 to version 4, Shama Ugale details the notable changes and deprecations you should be aware of. Check it out to see how to migrate to Selenium 4 safely.

Selenium 4 Relative Locators

Good, you’re up and running! One of the interesting new features of Selenium 4 that I really want you to try is Relative Locators. Selenium 4 Relative Locators seem pretty straightforward but I’ve covered some things to be aware of, and also how this is working under the covers.

Selenium 4: Chrome DevTools Protocol [What’s New]

And the biggest draw for Selenium 4 is arguably its programmatic access to the Chrome Devtools Protocol (CDP)! This is some super power stuff. Shama Ugale outlines some of the cool things you can now do right from within your tests using Selenium 4 and Chrome DevTools Protocol.

Selenium 4: Mocking Geolocation

I also have a livestream video where I used Selenium 4’s CDP API to mock a location in the browser! Pretty handy if you need to do any location-based testing.

Selenium Chrome DevTools Protocol (CDP) API: How Does It Work?

And then if you’re fascinated with all of this and want to really geek out, I talk about the architecture of the Selenium Chrome DevTools Protocol API, how it all works, and which method calls to use when (executeCdpCommand vs send).

Have fun and let me know what you think!

The post Selenium 4 Release Candidate is Here! appeared first on Automated Visual Testing | Applitools.

Selenium 4 introduces a new powerful API which grants access to Chrome DevTools directly from your automated tests! This is done via the Chrome DevTools Protocol (or CDP for short) which is essentially a set of tools that enables you to access and control Chromium-based browsers.

You may know Chrome DevTools as the place where you inspect elements to find their locators. But there are lots of other domains here as well such as Network, Performance, and Security. There’s also a bunch of commands and sensors available.

Selenium 4’s new Chromium DevTools API is essentially a wrapper around the raw CDP commands, and access to these commands from our tests opens a world of possibilities!

For example, we can mock the geolocation of our browser to do testing in areas where we aren’t actually physically located. We can simulate things like network speed and device mode. We can intercept network requests and mock responses. And we can capture console logs and performance metrics. Essentially anything that can be done from the Chrome DevTools window can now be done from our automated tests!

Shama Ugale has provided Selenium 4 CDP examples complete with code snippets! And in this post, I’ll provide the architecture to help you better understand how to use CDP in your tests.

ChromiumDriver

ChromiumDriver is a new driver that can be used to interact with Chromium-based browsers such as Google Chrome and Microsoft Edge. The browser-specific drivers ChromeDriver and EdgeDriver still exist in Selenium 4, but now they inherit from ChromiumDriver instead of the RemoteWebDriver class (which ChromiumDriver now extends).

From ChromiumDriver (or any of its children classes), you can now access the getDevTools() method which returns a DevTools object.

DevTools devTools = driver.getDevTools();

DevTools Object

The DevTools object has methods to manage CDP sessions, add and remove listeners, and most notably send CDP commands. The send() method accepts a Command, which are the Selenium-provided wrappers for CDP commands.

The wrapper classes represent the 45 CDP Domains and can all be found in the org.openqa.selenium.devtools.vXX package, where the vXX represents the browser version you’re running against.

For example, I’m currently using Chrome 88, so I must ensure I have the corresponding devtools dependency:

        <dependency>
            <groupId>org.seleniumhq.selenium</groupId>
            <artifactId>selenium-devtools-v88</artifactId>
            <version>4.0.0-beta-1</version>
        </dependency>

Here are the CDP Domains. Each of these have a corresponding wrapper class in Selenium 4.

By clicking on any of the CDP Domain links above, you’ll see the available commands. Each of these commands are methods within the Selenium domain wrapper classes. This makes it relatively straightforward to invoke a CDP command using the send() method.

For example, the signature for the send() method is

devTools.send(Command<X> command)

And if we wanted to invoke a command, we could do so by passing in the {Domain}.{command} to the send() method. Let’s say we wanted to clear the browser cache. The Network domain has a clearBrowserCache command, so this is what we’d use in Selenium as well.

devTools.send(Network.clearBrowserCache());

executeCdpCommand

Selenium 4 also provides the executeCdpCommand() method. I’m already seeing people jump straight to this method as opposed to the send() method, as the name is very enticing. The executeCdpCommand() method is available directly from ChromiumDriver (and its descendent classes). The purpose of this method is to allow you to invoke any raw CDP commands. As the devtools package has all of the ready-made wrappers available, the send() method should be your first choice to invoke CDP commands. The executeCdpCommand() method should be used when you want to bypass Selenium’s implementation and call the CDP commands directly. The use of executeCdpCommand() requires a bit more work, as you’ll need to paste in the exact Domain.command as well as a Map of all of the command’s parameters.

For example, here’s a call to emulate a geolocation using executeCdpCommand(). Notice, I need to manually type in the names for the Domain, command, parameters as well as the parameter values.

driver.executeCdpCommand(
        "Emulation.setGeolocationOverride",
        Map.of(
                "latitude", 30.3079823,
                "longitude", -97.893803,
                "accuracy", 1
        ));

And here’s the more streamlined way of invoking that same CDP command by using the DevTools API that Selenium provides. Here I only need to manually type in the values. Selenium takes care of everything else, so there’s less room for error.

devTools.send(Emulation.setGeolocationOverride(
        Optional.of(35.8235),
        Optional.of(-78.8256),
        Optional.of(100)));

Hopefully this helps you understand CDP better and how you may be able to take your tests to the next level!

The post Selenium Chrome DevTools Protocol (CDP) API: How Does It Work? appeared first on Automated Visual Testing | Applitools.

It’s been more than two years since we last evaluated Cypress vs Selenium WebDriver, and as we all know, a lot can happen in two years.

Since then, Selenium WebDriver has made impressive improvements as they prepare for the major release of Selenium 4, and Cypress has grown from its infancy phase. Let’s see what’s changed!

Target Audience

In our previous post, we asserted that most of Selenium’s users are testers, while developers seemed to favor Cypress. While this was certainly true in its early days, the popularity of Cypress has increased with testers as well. Cypress has become the most widely used test automation tool amongst our JavaScript users, which comprises mostly of dedicated automation engineers.

My theory for the uptick in the use of Cypress amongst testers is that collaboration is a key factor in tooling. It’s hard enough to get developers to contribute to UI testing, and if Cypress is a way to bridge that gap, then testers are all for it!

Language Support

Since Cypress was designed for frontend developers, it only supports JavaScript – the language of the web. This has not changed since Cypress was released, and it does not seem to be on the product’s roadmap. Consequentially, this puts Cypress at a disadvantage to Selenium which supports JavaScript as well as Java, Python, C#, Ruby, and Kotlin. This gives Selenium a much wider target audience, especially since Java is the most popular programming language for UI testing.

Browser Support

Arguably, the biggest enhancement to Cypress since our last post is its move from Chrome-only to cross browser support!

Cypress’ lack of cross-browser support was a major con for those who needed to test their applications on more than just Chrome. Many Cypress users had to rely on third-party plugins such as Applitools’ Ultrafast Grid to gain test coverage on multiple browsers. However, with version 4 of Cypress, this now opens the possibility of testing on Firefox and Edge as well.

Of course, Selenium WebDriver has always supported Chrome, Firefox, and IE; and has also supported Edge and Safari for years. This gives Selenium an edge in this category for those who need to test on Internet Explorer and Safari (the default browser for iOS devices).

Browser Capabilities

The architecture for Cypress and Selenium varies quite a bit (see our original comparison for the details). Cypress runs tests in-browser while Selenium uses a browser driver. Both of these approaches have their pros and cons.

Cypress tests are faster since there are less processes to call for every browser interaction. However, features such as opening and manipulating multiple tabs and windows is not supported in Cypress. Likewise, Cypress has limited support for working with iframes and requires you to write custom code to be able to do so.

Selenium users do not have to concern themselves with these limitations. Not only are iframes fully supported in WebDriver, but Selenium 4 boasts updated support for multiple windows and tabs.

Server Manipulation

In our previous post, we admired Cypress’ built-in support for mocking and intercepting server requests and responses. At that time, this powerful feature was not available in Selenium. However, Selenium 4 provides a brand new Chrome DevTools Protocol API which enables Selenium tests to not only mock server requests and intercept responses, but to fully leverage all of the possibilities of Chrome DevTools. This is a game-changing feature for Selenium WebDriver!

Which is Better? Selenium or Cypress?

That depends on your needs.

Cypress integrates quite nicely into a given production codebase making it favorable for developers, which therefore fares better for collaboration between developers and automation engineers/testers. Cypress’ architecture also inherently speeds up test execution.

However, Selenium has far more reach and support for browsers, programming languages, and browser capabilities.

If your application is relatively simple and speed and collaboration are the most important factors, then Cypress is a great choice. However, if your application and user journeys are more complex and require extensive testing across multiple platforms, then Selenium would be a better choice.

I applaud you for reading to the end! Tools have their intended purposes and while multiple tools may seem similar, we shouldn’t be so quick to label one tool as “better” than another. Evaluate any given tool against your requirements to determine which would be the most efficient for your needs.

I’m excited to see the progress in both Selenium WebDriver and Cypress over the last two years. Both are clearly here to stay!

The post Selenium vs Cypress: The Rematch appeared first on Automated Visual Testing | Applitools.

• What is Selenium Grid?
• Why should one consider using Selenium Grid?
• How does the Selenium Grid work?
• Selenium Grid 3 vs Selenium Grid 4
• Limitations of using Selenium Grid
• Applitools Ultrafast Grid
• Summary

What is Selenium Grid?

Selenium Grid is a component of the Selenium suite which enables us to distribute the tests in parallel on various combinations of browsers, operating systems, and machines saving us a lot of execution time.

Selenium Grid lets you pursue the two apparently contradictory requirements for app testing: increase test coverage and decrease test time.

Why should one consider using Selenium Grid?

Businesses are adopting agile practices to reach their users rapidly & frequently. To do this, they need to ensure the application works seamlessly across all browsers/devices and platforms.

Test automation plays a vital role in providing quick feedback on quality in order to enable these quick releases.

However, it is a challenge to achieve quick and reliable feedback with the growing number of automated tests.

To overcome the challenge of speed and scale across browsers, we can execute the automated tests in parallel using the Selenium Grid.

In this post of the Selenium 4 series we will discuss:

• Running tests in parallel across multiple browsers / platform combinations using Selenium Grid
• Differences in Selenium Grid 3 & Selenium Grid 4
• Challenges/limitations of using the Selenium Grid
• Enhanced scaling and reduced flakiness by using Applitools Ultrafast Test Cloud

How does the Selenium Grid work?

The major components of Grid are a hub and a node. The Selenium server is set up as a hub and nodes.

The hub receives a test to be executed along with information on which browser (Chrome, IE, Firefox, Safari, etc) and ‘platform’ (WINDOWS, LINUX, etc) where the test should be run. This information is passed to the Grid by setting up the capabilities and sending it to the driver constructor.  

With the hub having the list of nodes registered under it, it then selects an available node that has the requested browser-platform combination, initiates Selenium commands and passes them to the node selected. The node runs the browser and executes the test case.

Selenium Grid 3 vs Selenium Grid 4

The hub and nodes are the only components of the Selenium Grid 3. The only way to set up a grid with Selenium Grid 3 is as a Hub-Node setup.

The grid can be set up as a hub and one or more nodes registered to it. The hub and the nodes can be set up on single or separate machines. All the machines should have the selenium-standalone jar to be downloaded as a hub to represent as a hub in the cluster and a node to represent as a node with separate commands.

Selenium Grid 3 can be visualized as shown in the below diagram.

With Selenium 4, the Grid has been rewritten from scratch with all modern tools and frameworks to support fully distributed testing and comes with extensive docker support.  

Diagram: Selenium 4 Architecture from selenium.dev

Grid 4 has additional components to hub and node and enable the distributed testing and scaling of the test execution namely:

• Router: Listens to all incoming requests and performs load balancing
• Distributor: Listens to the new session requests and forwards it to the right Node matching the capabilities
• Session Map: A key-value data store that stores information of the session under execution
• Event Bus: Forms the communication bridge between the Node, Distributor and the Session Map

The hub is the collection of all the four components above.

More on new Selenium Grid 4 architecture can be found in the official documentation.

Selenium Grid 4 can be setup in various different ways

1. Standalone: Single machine registered as a hub and a node
2. Hub and Node: Single hub and multiple nodes on different machines and registered to the hub

1. Distributed: Run the components of Selenium Grid individually as separate processes
2. Docker: Run the Selenium Grid with docker and use docker for creating new instances

Limitations of using Selenium Grid

While the Selenium Grid helps us to cover the cross-browser/platform testing and reducing the test execution time by running the tests in parallel, it also may bring in some challenges such as:

• Overhead of maintaining and procuring infrastructure
• The need for a dedicated machine setup
• Brittle tests due to infrastructure variations and re-running the same tests on multiple browsers  
• Limitations on scaling based on underlying resources on the machine

Moreover, the approach of running each test across different browsers and devices still takes considerable execution time and may not be an efficient approach since the functionality rarely changes between browsers adhering to the W3C protocol, and there are more efficient ways to test the visual rendering across all environments while checking the functionality once to avoid the flakiness involved with running the test 10 times.

Applitools Ultrafast Grid

Applitools’s Ultrafast Grid brings the best of the two worlds covering functional and visual testing with a single run.

Using the Applitools Ultrafast Grid, the test is run once on a local machine on any browser and the Ultrafast Grid renders the application with all the combinations of the major browsers/platforms and devices on cloud, thus achieving the visual and the functional test coverage with a single run.

The Applitools Ultrafast Grid doesn’t need any additional infra setup or a Browser / device lab locally or in the cloud, thus eliminating the need to maintain, setup and monitor the dedicated infrastructure for cross browser testing.

Applitools Ultrafast Grid supports the rendering browser and devices listed below:

• Browsers: Chrome, Firefox, Microsoft Edge, Safari, Microsoft IE 10, Microsoft IE 11
• Mobile Web: iPhone and iPad devices, Samsung Galaxy devices, Kindle

Applitools’s Ultrafast Grid makes the execution faster by leveraging the Visual AI rendering and thus lowers the test maintenance and eliminates the false alarms.

To learn how to set up the Ultrafast Grid, refer to the official documentation.

Summary

In this we discussed how Selenium Grid works and how Selenium Grid 4 differs from Grid 3. We also discussed new components and the architecture of Grid 4 and the various ways it can be set up and used. We also have learnt the need to run the tests in parallel and how business can be benefited by setting up the right automation strategy and going faster to the market by using Ultrafast Grid offered by Applitools covering not only the functional tests but additionally the visual rendering too.

In the next post we shall see how Selenium Grid 4 can be set up in various ways with the use cases.

The post Selenium Grid 4 appeared first on Automated Visual Testing | Applitools.

The Selenium WebDriver maintainers have been hard at work on a brand-new version: Selenium 4!

Some of the features are already available in alpha mode — which allows us the opportunity to try it out, provide feedback, and even pitch in with development.

Watch this webinar, where Angie Jones explored some of the most promising new capabilities of Selenium 4.

Angie also took for a test-drive some of its new features such as Relative Locators, Chrome Devtools Protocol (CDP), Window Management, and more.

You know Angie – so you know code samples were provided!

Angie’s Slide Deck

https://slides.com/angiejones/selenium4/fullscreen

Full Webinar Recording

Additional Selenium 4 Resources

• What’s New In Selenium 4? — post by Manoj Kumar
• Selenium 4 – New Features of Selenium WebDriver (Part 1) — post by Shama Ugale
• How to Install Selenium 4 — post by Shama Ugale
• Migrating to Selenium 4: Here’s What Has Changed — post by Shama Ugale

• Angie Jones Presents: “Automated Visual Testing: A Fast Path To Test Automation Success” — ace automated visual testing with this free 9-chapter online course, exclusive on Test Automation University!
• Test Automation University exclusive — Selenium WebDriver with Java — 14-chapter intro course by Angie Jones, to advanced Selenium WebDriver with Java.
• Start visually testing your app and site today, with your free Applitools account — Click here

— HAPPY TESTING —

The post Test Driving Selenium 4 – with Angie Jones [webinar recording] appeared first on Automated Visual Testing | Applitools.

A guide to notable changes and deprecations for engineers looking to migrate from Selenium 3 to Selenium 4.

There is huge excitement within the testing community since Simon Stewart, the lead of the Selenium project, announced the release of Selenium 4 with major changes and W3C standardization to the Selenium suite (Selenium IDE, Selenium WebDriver and Selenium Grid) during the official Selenium Conference 2018 at Bangalore, India.

As of early September 2020, the alpha version of Selenium 4 is available and can be downloaded to explore.

Manoj Kumar has already explained at a high level what’s new in Selenium 4, and in this weekly blog series, we will discuss these features in detail with code snippets, benefits and possible use cases for the end users and well as the dev community who have built tools/products on top of Selenium.

Key takeaways

• Understand the deprecated components and their replacements
• Plan the migration from Selenium 3 to 4

Selenium is a toolset for web browser automation that allows us to remotely control browser instances and emulate a user’s interaction with the browser. There are many changes in Selenium 4, the major being the W3C standardization, which implies that Selenium can be integrated with any software without any compatibility issues. Along with W3C standardization, there are few new methods added and deprecated/replaced.

Let’s discuss these in detail.

What’s been deprecated in Selenium 4?

There are a couple of deprecations in Selenium 4. Let’s explore them.

FindsBy

FindsBy interfaces are part of org.openqa.selenium.internal package having findElement(By) and findElements(By) methods, implemented by the RemoteWebDriver class. These are now deprecated as part of Selenium 4.

This is an internal change and does not impact end users, however if you have a product or tool built on top of Selenium APIs, have a look into these changes.

The By class can be used with findElement(By) and findElements(By) just like before.

Actions

The Actions class is a user-facing API for emulating complex user gestures like hovering, mouse movements, etc.

A few new methods have been added to the Actions class as a replacement of the classes under package org.openqa.selenium.interactions:

click

A new method click(WebElement) is added to Actions class and is a replacement of moveToElement(onElement).click() and is used to click on an element.

clickAndHold

Similarly, clickAndHold(WebElement) is used to click on an element without releasing and should be used as an replacement of moveToElement(onElement).clickAndHold()

contextClick

contextClick(WebElement) is a replacement of moveToElement(onElement).contextClick() which was used to right click on an element.

doubleClick

doubleClick(WebElement) is used to double click on an element and is a replacement of moveToElement(element).doubleClick().

release

release() is used to release the depressed left mouse button at the current mouse location. This was earlier part of org.openqa.selenium.interactions.ButtonReleaseAction class, and is now moved to Actions class.

Examples

The below example demonstrates the usage of Actions methods discussed in Selenium 3 from line 17 to 33.

These methods can be replaced as shown in the below code snippet as part of Selenium 4 implementation from line 37 to 53.

FluentWait

The methods withTimeout() and pollingEvery() from FluentWait class have been changed. Now both methods accept a single parameter java.time.Duration in replacement of two parameters int and TimeUnit. Lets see the usages.

In the Selenium 3 example below, we see on line 6, the pollingEvery() method takes two parameters int and TimeUnit and can be imported from the package java.util.concurrent.TimeUnit. On line 7, withTimeout() also accepts int and TimeUnit as parameters.

Selenium 4 has replaced the TimeUnit with Duration and here is the sample code snippet demonstrating it. On line 12, pollingEvery() method now accepts only one parameter, Duration.

The Duration class can be imported from the java.time package and has methods to represent time duration in nano, millis, seconds, minutes, hours, days and so on.

In our example we have used ofMillis(int) and ofSeconds(int) methods.

Similarly, on line 14 withTimeout() method accepts Duration as a parameter.

Driver Constructors

A couple of driver constructors have been deprecated. Namely, the ones that accepted Capabilities objects have been replaced with ones that accept Options.

This means you will need to create a specific Options object for whichever Driver class you’re using, set your requirements and pass this object to the Driver constructor.

Examples for each of the drivers can are below

ChromeDriver

ChromeDriver(Capabilities) is replaced by ChromeDriver(ChromeOptions).

SafariDriver

SafariDriver(Capabilities) is replaced by SafariDriver(SafariOptions).

EdgeDriver

EgdeDriver(Capabilities) is replaced by EdgeDriver(EdgeOptions).

FirefoxDriver

FirefoxDriver(Capabilities) is replaced by FirefoxDriver(FirefoxOptions).

InternetExplorerDriver

InternetExplorerDriver(Capabilities) is replaced by InternetExplorerDriver(InternetExplorerOptions).

Summary

We went through the major deprecations in Selenium 4 and have outlined the ones that are important for end users in their migration from Selenium 3 to 4.

The list of all deprecations can be explored in the Selenium WebDriver API docs. There are considerable internal interfaces, classes and ENUMs deprecated which have no impact on end users but may be of importance to vendors of tools and products built on top of Selenium.

In the next post of this series, we will explore the newly added features offered in Selenium 4 and the benefits they provide.

About the Author

Shama Ugale is a quality assurance specialist at Thoughtworks. She has great knowledge about Selenium project and Selenium 4 that she is happy to share with you. You can finder on LinkedIn at https://www.linkedin.com/in/shama-ugale-7a95b549/

The post Migrating to Selenium 4: Here’s What Has Changed appeared first on Automated Visual Testing | Applitools.