What will you learn in this course?
Are you struggling with working with HTML using Selenium WebDriver? Do you know how to easily identify and manipulate an element using Selenium WebDriver? How about performing a drag n’ drop on an element? If not, then these are just a few of the questions that will be answered in this course.
This course is a complete guide on working with web elements in Selenium WebDriver! Once you are finished with this course, you will know how to work with any web elements, anytime, on any web application.
In this course from Ultimate QA, you will learn:
– Basics of HTML
– All the different locator strategies for Selenium WebDriver
– How to identify web elements using Selenium WebDriver
– Master XPath
– Navigation with Selenium WebDriver
– Web element manipulation
– Web element interrogation
– Mouse and keyboard actions with Selenium WebDriver
– Performing actions such as drag n’ drop, drawing, hovering
– Implicit and Explicit waits
– How to properly handle element identification so that your tests are not flaky
– Expected Conditions in Selenium WebDriver
What will you learn in this lecture?
In this video, we will go through the conclusions of the Implicit and Explicit Waits course.
Selenium Tutorial – Implicit and Explicit Waits Conclusions
Ok awesome So let’s go ahead and do a quick recap of everything that you all have learned so that it is better sustained inside of your memory.
So we began this course by understanding why synchronization is important right.
And there were several points of why synchronization is important is it leads to intermittent failures.
It leads to false positives and negatives.
And it’s leads to slower test execution time.
So all of these kind of make your tests seem flaky and when your tests seem flaky it not only demoralises you demoralises your team and therefore they start to trust automation less which is a really bad situation to be in when nobody trusts your automated software testing because they’re like all these tests you know they never give us the right result. So if they never give us the right result why should we trust it now. And so now you have to win back the trust of your entire team by showing them why your tests are good. So that’s a situation that you never want to get into. So after we learned why synchronisation is so important we learned several different types of selenium timeouts that exist. And those are implicit time outs if you remembered are those defined by selenium webdriver it’s just the driver that managed out timeouts that implicitly wait and then you specify the amount of time that you want the webdriver to wait is great because it’s easier to use. It’s bad because once you define that time out that lasts for the entire duration of the driver. And so therefore that’s not good because sometimes your elements may load slower sometimes they may load faster. And so you don’t want a timeout stuck on your driver because that can lead to again false positives and false negatives. So then we moved on to learning why and how to fix the implicit waits problem.
And that was using the explicit waits and the explicit waits war code that you define in order for webdriver to wait for an element to be in a certain state. Right. It can be as bad as thread sleep. That’s an explicit waits because you defined the code however you should never use it because the read that sleep is a static timeout that has similar implications as to the implicit waits thread that Salif is just really bad because it’s just pure hard coding. And whenever your environment is either running faster or slower you’re going to run into trouble because your tests again are going to be flaky. So finally what we settled upon was using the webdriver waits class and expected conditions the expected conditions. Class has a bunch of predefined conditions that selenium bindings have for us like element as visible element exists. Wait until element is in the DOM wait until alert is present and so on and so forth and all of those allow us to interact with different elements under different conditions to get a specific result that we desire. And then finally after explicit waits we learned about fluent Waites. But remember that the fluent way are only in Java because this is the parent class from which webdriver waits inherit. So in the C# bindings This is known as a default waits. So the default wait is nice because it allows us to granularly getting into the waiting class and defined messaging the polling. The exceptions should be ignored and all the conditions.
But the problem with it is that it is a bit hefty to utilize and it’s not very practical there and there is no need to really use that because the web drive wait class kind of wraps the default wait class and gives us all the functionality that we need in a single line of code as opposed to about five or six line of codes that the default waits requires for us to set up and make it work. And so that’s about it. I had a fun tutorial with you guys. Thanks again for tuning in and see you all next time.