Selenium 4 - and its bucket of surprises

-



 Selenium 4 - and its bucket of surprises



Selenium 4 is about to be released by the end of this year, which makes a lot of us wonder - what surprises are we in for?

Selenium-webdriver is the number one free open source testing framework which is being used by many organization as their main reliance for UI test automation. Selenium's API is also partially used by different free and commercial testing tools. With that being said, we should try and better understand our mysterious partner for automation adventures. Let's review in a nutshell some of the things that are in the bucket for the upcoming version.

In this upcoming version, we are in for some new treats

Selenium IDE is being revived :
As some of us may remember, In August of 2017 it was announced that as of Firefox 55 Selenium IDE would no longer be supported. Selenium IDE or as the Selenium community refers to it - the Legacy IDE was, and is, dead. Since then a lot has happened with it. The Selenium community along with commercial companions such as Applitools have picked up the glove and contributed to the new - Selenium IDE.
For this upcoming version it is in progress, and according to GitHub documentation, it will be a complete rewrite of the old one. The older IDE was a Firefox extension that relied heavily on APIs that are no longer supported by newer versions of Firefox. In this newer version, the IDE is developed as a new browser extension, claiming to support both Chrome and Firefox. In theory, other browser vendors will be able to plug-in as well.
As far as I'm concerned, the bigger question is - will they be able to fix and remake all that was wrong with the "Legacy IDE". (Locators, Iframes, condition support etc.)

Selenium standalone-server
Furthermore, we are in for some improvements in Selenium standalone server in both its UI, logging and setup procedures. Allegedly making the configuration and user experience more friendly. If you ever tried to set up and configure a Selenium grid you must know that is it not the most fun experience, so I'm really looking forward to seeing the changes made.

Standardization
Probably the most significant technical change is the standardization.
The webdriver API is expected to be completely W3C standardized in Selenium 4. As we all know the Selenium webdriver API has grown past the specific framework and is used by other frameworks and tools (such as Appium for example). This is one of the reasons to aspire to become single-standard and compatible across implementations of the webdriver API.


Before we dive into that, let us do a quick recall about what went on in the previous versions.
Our (Code) bindings (for example, Java) implement the WebDriver Interface which communicates with different browser drivers via HTTP commands. In the previous versions, the main difference between Selenium 2 and Selenium 3 was that in Selenium 2 it was the Selenium project who was responsible to provide the driver for each browser. In Selenium 3 that responsibility was transferred to the browser vendors that required them to ship their own WebDriver implementations. The reasoning for that was that they know their browsers the best, and hopefully, the produced drivers were supposed to be much more stable and robust. (Tell that to IE driver users).
That was in theory, in reality - Selenium users had some unpleasant experiences due to the fact that some drivers did not fully support the webdriver interface and had to deal with it. 
A good example is broken clicks that have been reported by Selenium 3 users during nov' 2016 and "sendKeys" command that failed to be invoked.
Basically, up until now, all drivers accept geckodriver (Firefox) supported both protocols. gecko stopped supporting JSON wire protocol starting Selenium 3. 



I made this sheet so you could take a closer look at some of the changes in the W3C HTTP protocol vs the Older JSON wire protocol implementation:



Continuing this topic In Selenium 4 we will see deprecated functions,  added capabilities and changes in the protocol structure.

You can take a look at these changes made to the capabilities and node configurations from the latest version update. That in addition to the node config structure that has slightly changed (For example the "configuration" attribute will not work in the new version of the standalone server).


In conclusion
The latest version claims to be better and improved, with updated official documentation and will require minimum code changes. All that's left for us is to wait for its release so we can touch and feel the fresh version. 









Comments

  1. Doron BarSeptember 16, 2018 at 10:34 AM

    Great, I will send it to my team!

    ReplyDelete
    Replies
    1. Daniel GoldSeptember 16, 2018 at 11:31 AM

      Thank you for your kind feedback! :)

      Delete
  2. Julia VolSeptember 16, 2018 at 11:13 PM

    Very thorough article, thank you!

    ReplyDelete
  3. Yonit Trabelsi-ElbazSeptember 17, 2018 at 2:41 AM

    Thank U Daniel , great article

    ReplyDelete
  4. Den FyrenNovember 16, 2020 at 6:57 AM

    Isn't it about time you deleted this article now? Selenium is dead, period. There hasn't been any development in more than 2 years, and just about all professional developers are moving to Cypress. Why? Selenium doesn't work anymore. My company has wasted idiotic amounts of money trying to get Selenium to work with Angular9 applications. It can't be done. Over. Finito.

    ReplyDelete

Post a Comment

Popular posts from this blog

Sharing is caring - Intro to Jenkins shared libraries

-
Image
  Whether you're just dipping your toes into the world of automation infrastructure, or already crafting your first jobs to automate your test execution, Jenkins is your new best friend.  In this blog post, we will talk a bit more about the practice of infrastructure as code, its relevance to test automation, and how you can avoid code duplications, align with industry best practices, and enable velocity, maintainability, and collaboration. So, whether you're a seasoned pro or just starting out, let's dive into the world of Jenkins Shared Libraries and see how they can make your life easier. Jenkins Shared Libraries play a crucial role in the realm of Infrastructure as Code (IaC).  So, what are they exactly? Think of Jenkins Shared Libraries as your secret stash of code snippets, neatly organized and ready to be plugged into your pipelines whenever needed. Let's explore the aspect of reusability within Jenkins Shared Libraries: Reusability is the cornerstone of efficien...
Read more

Intro to Terraform and how it is related to test automation infrastructure

-
Image
In this post, we will take a closer look at one of the most popular infrastructure-as-code software tools developed by HashiCorp, and if you follow my recent content, that name should start ringing a few bells. So, what is Terraform and why do we need it? Terraform allows you to define and describe your infrastructure in the form of code. To be more specific “HashiCorp declarative configuration language” (or HCL in short). With Terraform you can manage your resources and infrastructure modules like servers, VPCs, security groups, and much more, even if they are located on different providers such as AWS or Azure.  Generally speaking, cloud providers have their own infrastructure-as-code tools like CloudFormation or ARM. But, Terraform has very extensive support for different cloud providers and platforms allowing you to use a single tool for cross-cloud configurations. This makes it easier to manage your resources, easier to onboard and this is a scalable and in general, the “best ...
Read more

Test Automation, Security, and other vegetables

-
Image
Automation, Security, and other vegetables What is commonly overlooked when focusing on Quality? In this blog post, I want to delve into an aspect commonly overlooked in the context of Test Automation, and that’s the Security aspect.  As test automation developers, we often overlook the basic fact that we are working on a software project. Just like any other software project, considering security in our test automation practices adds a vital layer of protection to our work environment and helps ensure that our work which was initially meant to save time and help quality efforts, will not provide an easy and accessible breach point to our application.  So, on this note, let’s dive into why security should be an integral part of our automation efforts and explore some strategies to ensure our project is as effective as it is secure.  Analyze the attack surface - Before we can effectively secure our test automation infrastructure, it's crucial to identify and analyze poten...
Read more