In This Course
In this course, you will:
1. Learn the problems that can occur as a result of improper synchronization
2. Learn how to use Selenium Webdriver explicit waits
3. Master Selenium Webdriver implicit wait
4. Understand what a DefaultWait is
5. Comprehend how to use all of the different types of waits during appropriate situations
In this Lecture
This discussions gives an overall view of the topics that were discussed throughout this course. You’ll get a brief input on each of the topics. Furthermore, this summary can help guide you when using the Selenium WebDriver in the future.
Selenium Tutorial – Selenium WebDriver Conclusions
Okay, awesome. Let’s go ahead and do a quick recap of everything that you all have learned so it’s better sustained inside over your memory.
We began this course by understanding why synchronization is important. There were several points of why synchronization is important. It leads to intermittent test failure, it leads to false positives and negatives and, it leads to slower test execution time.
All of these make your tests seem flaky and when you’re tests seem flaky, it not only demoralizes you, it demoralizes your team. Therefore, they start to trust automation less which is a really bad situation to be and when nobody trust your automated software testing because they are like, “These tests they never give us the right result so if they never give us the right result why should be trusted now.”
Now, you have to win back the trust of your entire team by showing them why your tests are good so that’s the situation that you never want to get into. After we learned why synchronization is so important, we learned several different types of Selenium timeouts that exist and those are implicit.
Implicit timeouts if you remembered are those defined by Selenium Webdriver. It’s just the driver.manage.timeouts that implicitly wait and then you specify the amount of time that you want WebDriver to wait. This is great because it’s easy to use. However, it is also bad because once you define that timeout that lasts for the entire duration of the driver.
Therefore, that’s not good because sometimes your elements may load slower. Also, 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.
Then, we moved on to learning why and how to fix the implicit wait problem and that was using the explicit wait. The explicit waits were codes that you define in order for WebDriver to wait for an element to be in a certain state. It can be as bad as thread.sleep. That’s an explicit wait because you define the code.
However, you should never use it because thread.sleep is a static timeout that has similar implications as to the implicit wait. Thread.sleep is just really bad because it’s just pure hard coding. And whenever your environment is either running faster or slower you going to run into trouble. It is because your test again are going to be flaky.
What we settled upon was using the WebDriverWait class and ExpectedConditions. The ExpectedConditions class has a bunch of predefined conditions that’s Selenium bindings have for us like ElementIsVisible, ElementExists, wait until element is in the DOM, wait until alert is present and so on and so forth and all of those allows us to interact with different elements under different conditions to get a specific result that we desire.
Then finally, after explicit waits be learned about fluent waits but remember that fluent waits are only in Java. It is because this is the parent class from which WebDriverWait inherits. That is why in the C# bindings this is known as the DefaultWait.
The DefaultWait is nice. It allows us to granularly get in to the waiting class and define the messaging, the polling, the exceptions to 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 is no need to really use it because the WebDriverWait class kind of wraps the DefaultWait class. Also, it gives the soul to functionality that we need in a single line of code. As opposed five or six lines of codes that the DefaultWait requires for us to set up and make it work and so that’s about it. I had fun tutorial with you guys. Thanks again for tuning in and see you all next time.
Nikolay Advolodkin is a self-driven SDET on a lifelong mission to create profound change in the IT world and ultimately leave a legacy for his loved ones, community, and the world at large. Today, he serves as the CEO and Test Automation Instructor at UltimateQA.com and contributes informative articles to leading test automaton websites like SimpleProgrammer.com and TechBeacon.com