Softening Changes up Selenium - How We Handled Them

On the off chance that you are in the matter of making Quality Software, consistently can hurl an amazement or two. How one beats these everyday difficulties regularly characterizes the course of your prosperity. Here's one such test we as of late confronted, we thought of offering to you. We would love to hear your input.

Like any great programming designer, we tend to regard breaking in reverse similarity as a wrongdoing and strive to shield our end-clients from confronting any outcomes coming about because of surprising changes. All things considered, we experience a daily reality such that change is the main consistent! It's dependably a test to ingest the progressions.

For our Scriptless Test Automation stage, we utilize Selenium WebDriver to interface with the Browsers. We by and large utilize a steady form of Selenium webdriver as a benchmark for our own advancement. In any case, we wind up supporting various variants and mixes of bolstered programs/OS blends, as our clients request it. Amid the relapse period of a specific item refresh discharge, our QA group revealed an issue that all the mouse activities (MouseHover, MouseUp, MouseDown) were not working with the Selenium WebDriver rendition 3.6+

We explored the issue and assumed that inside mouse activities (in the Qualitia Engine code), we utilize Locatable APIs. We found that these Locatable API had been refactored (and in addition censured) by Selenium people group in SE 3.6+ and the group prescribed to utilize Actions API which they upheld since SE 3.0+.

In spite of the fact that the test, from this time forward, would have been keeping up in reverse similarity with Selenium forms in Qualitia (in any event post SE 3.0), any of the above changes would be straightforward in the event that we couldn't have cared less about in reverse similarity. Be that as it may, at that point in a perfect world we have clients utilizing different Selenium 3.x adaptations. We had no alternative however to settle this issue in Qualitia 5.0 of every a way which works over all the Selenium 3.x forms.

We additionally made sense of that Locatable is a crude method for getting to mouse activities so the group was compelled to move to Actions API and henceforth, they couldn't have cared less refactoring them. This basically caused breaking changes. Subsequent to conceptualizing, we could think of a couple of methodologies as answers for this issue:

Potential Solution 1: The seemiingly evident arrangement was to supplant Locatable bundle explanations with new bundle structure articulations (which SE 3.6 had presented) and gather the code with Selenium 3.6. The code would have effectively gathered. Nonetheless, it would have tossed runtime special case for those mouse activities (MouseHover, MouseUp, MouseDown). This would occur since Java wouldn't discover the bundle structure in prior renditions, which is implied for SE 3.6. We dropped this arrangement.

Potential Solution 2: Use Locatable APIs and compose code to deal with Mouse activities in Selenium form in a rationalist way. The thought was, if mouse activities fall flat at runtime (because of unforeseen bundle import) get that Exception (which implies client must utilize pre-SE 3.6 variant) and expressly call the Pre SE 3.6 bundle structure (i.e. more established completely qualified Locatable bundle to conjure Mouse activities on Pre SE 3.6).

The pseudo code would look something as takes after:

attempt

{

/SE 3.6 dealing with

Locatable driver = (Locatable) webDriver;

Mouse = driver.getMouse();

mouse.click(getCoordinates());

}

catch(RunTimeException e)

{

/Pre-SE 3.6-dealing with

com.newstructure.Locatable = (com.newstructure.Locatable) webDriver

Mouse = driver.getMouse();

mouse.click(getCoordinates());

}

This Selenium rendition particular special case based code and utilizing expostulated Locatable didn't appear to be perfect and promising way. Making Selenium rendition suppositions for the run-time special case can transform whenever into a fiasco.

Potential Solution 3: Use Actions API and change the whole execution while keeping up the retrogressive similarity. Since Actions API is bolstered post 3.0+, it would be exceptionally sheltered to utilize them. In addition, SE people group additionally prescribes to utilize them over crude method for utilizing Locatable mouse activity. We additionally accomplish in reverse equivalence. There would be no effect to the Qualitia client, since for her, in her scriptless Qualitia steps, mouse activity name and parameters would continue as before. (Albeit, actually, the parameters would get overlooked in the most recent API, however that won't break anything for the client.)

We chose to go for Solution 3. For the Qualitia User, nothing changes as we chose to live with alternatively tolerating the parameters, which are not utilized by the API. The old experiments will keep on functioning with no effect. The Qualitia client would euphorically be ignorant of the progressions occurring in the engine!

With help from its energetic group and the always advancing scene of program based innovations, Selenium will keep on evolving! It's likewise expected that every so often we need to confront breaking changes. We should endeavor to keep our code however much future-verification as could reasonably be expected and keep up in reverse similarity, at the same time.