Simply by wrapping the selenium execute operate with our personal model of it, you may make your take a look at framework extra strong and your exams far more dependable
Whereas selenium is extraordinarily standard at the moment in UI take a look at automation and different browser-related automation efforts it’s fairly unreliable and is thought to throw all types of errors whereas interacting with the DOM.
Frequent exceptions thrown embrace:
Once we first encounter these errors our go-to resolution is to wrap the selenium technique with an express wait.
Whereas this resolution is suitable, I’d argue that having too many express waits in every single place in your code can actually make your codebase bloated and ugly-looking.
So, on this article, I wish to counsel a quite simple mechanism of retry that may be baked into your selenium calls which might deal with the vast majority of these errors while not having an express wait in every single place in your code.
Earlier than we resort to utilizing express waits we should always take into consideration the randomness facet of utilizing browsers usually. There are such a lot of issues that may go flawed from sudden pop-ups, sources not loading fully, components overlapping different components and blocking interplay, and lots of extra.
Because it seems, a easy retry of the identical name is surprisingly highly effective and efficient in dealing with quite a lot of this randomness and if the take a look at nonetheless fails after this you may be certain you might be dealing with the very excessive instances
I’m going to be demonstrating this resolution in Python however you possibly can be at liberty to implement this in any language you need. The operate on the coronary heart of that is the execute operate in selenium which we will probably be wrapping by our personal model of it.
First outline the selenium exceptions you wish to deal with in your retry logic
I’ve compiled this listing of exceptions as a result of most of those may be attributed to the browser randomness we talked about and our retry logic ought to deal with these.
If you need to try the whole listing of selenium exceptions you possibly can go here.
Subsequent, we’ll write our personal execute operate
All this operate does is it takes the reference to the selenium’s to execute operate and runs it however provides a handler for the above exceptions which merely simply reruns the execute once more after a quick delay of 1 second. That is it!
Now how can we inform selenium to make use of this executed model as an alternative of its personal?
Identical to we wrapped the selenium execute operate with our personal model of execute i.e
selenium_execute_with_retry, we’re going to wrap all the selenium with our personal model of it referred to as
selenium_wrapper which simply replaces the execute operate with our model of it.
To verify we solely do that on the vanilla selenium, I’ve added a
_patched attribute to point that that is our patched selenium and never the vanilla selenium.
Now to make use of our patched model of selenium simply instantiate the browser as you usually would and cross it to the wrapper.
The ensuing browser object in line 2 is now going to have our model of the execute operate and never the vanilla model.
Over time of growing my very own automation frameworks, I now use this resolution in all my frameworks so as to add an additional layer of robustness and filter out the random and peculiar failures. Because it seems it was only a easy retry.