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 what can change about the Keyword Driven Framework of the page objects in test automation course.
Selenium Tutorial – Page Objects in Test Automation What can change about the Keyword Driven Framework
So the question that I want to post to you now is do you believe that with the keyword driven approach that these tests have illuminated enough possible sources of change to actually be stable and not be classified as brutal again. Sadly I don’t think so. I believe that key words are given to us although they are amazing step up from a record to us. They still have a ton of problems that will cause you to spend a lot of time debugging and not be able to maintain your automation frameworks. I remember many years ago when I was writing Cambridge given to us it was actually utilizing QBP.
I remember how hard over time we had automating tests utilizing the keywords or in the framework can be we’re doing a pretty good job. We had a good team of really smart people writing key driven tests because we thought that that’s the best approach and we still would spend weeks trying to make a single test pass. Granted we were doing a lot of things wrong but again we were all utilizing that keyboard driven approach and we were wondering why is this so hard. Why is our automation so brittle that it takes us weeks to put out an automated functional to us.
It was really sad but it is a good lesson because we thought that was the right way we thought that this is the way that it should be done without realizing it. And that’s what I want to help you guys here with today to be able to understand that there are better ways regardless.
So the first main issue that I see with the coverage given to us is that they are still wet. We are still writing everything twice. They’re not dry and they don’t follow the DRY principle. For example take a look at test number one lines 19 and 20. How does two methods along even with this verification they are repeated here and test two. And they’re also repeated in tests three in fact almost this entire test is of repetition in each of the tests. And yes of course I know that these tests are literally duplicates because I just copied and pasted them.
But you can see how from scenario to Scenario A lot of steps can still be repeated Right because our steps were just logging into an application. That’s one of the very basic features of every application and we can take it into many different directions from there. We can start logging in and then validating that a video opens we can start logging in and then validating that we can select the video we can go in validate that we can go through an entire course.
There are many different kinds of functionalities but they all have this log in functionality in common and it is all being repeated through all of our tests. So whenever we make any kinds of changes for example a synchronization change because our application is now slower or for whatever reason maybe it’s we introduced a bug that’s making our application slower. So now for example if we have to deal with the synchronization point we might need to come here and replace this implicit wait with an explicit way to be able to better handle the loading of the application.
And so now we have to apply this change to all of our five hundred tests as opposed to a single place. I actually had that happen to me recently where I had a bunch of Turse I think a few thousand times that were running. And then when I look back at the results I saw that there were about 100000 that had actually failed. And it was really interesting to me that that failed because I was like what’s going on. And then when I further analyzed why the tests failed it was actually because our application I think had gotten a little bit slower. And so what had happened was the test was running too fast for the application. And so now it was failing because there was a bad synchronization point and saw what I had to do was go away and of the the synchronization point and then that fixed my 100 Tests.
The beauty of it was that I fixed the synchronization pointed at a single place rather than all of these other places and all of the tests. And that made my fix really quick and really easy and then the test passed right after I finished running them. But it does happen synchronization issues happen all the time. And my point is that you need to be prepared for those changes as good as you can. And unfortunately the key words in the framework approach doesn’t really prepare us as well as it can. Some other issues that can actually occur with a keyword driven framework that will break all of your tests our flow changes.
Right so here in my in this current flow I’m logging in but I am logging in with a browser in a standard maximum window size. What if now I needed a test that logs in with a browser in half size would if I knew to have the logs in with a browser in a mobile window write that functionality is different and it needs to be handled different. And so what am I going to do am I going to create a completely new keyboard to be able to log in in a different kind of mode or should I have one method that handles both of the situations depending on which situation you’re in.
I would argue that the method is a better approach because you decrease your duplication of code and all of the methods and now you’re just stuck with one method as opposed to two methods that you need to maintain. But the final piece of the puzzle that can actually break a bunch of our automated functional tests is a change to our actual driver. Yeah that’s right. Selenium can disappear at some point it may no longer be relevant and you might need to replace it. So all of our tests that are using these find elements all of these hard coded methods for selenium web driver they’re going to break and you’re going to need to replace that with an entirely new driver. And if you don’t believe me that the driver can change. Take a look at Google Trends with me for a second. I’m sure that a lot of you guys remember QBP right.
And here in Google Trends what I did was I just compared the popularity of cuchi versus selenium web driver and down here you can see GGP versus solanine web drive or searches over time. So take a look back in 2011 TGP used to be really popular and selenium web driver did it. And now over time that is actually reverse where so many drivers are becoming more popular than GTP. Yes those are Google search trends. But what it should also tell you is that Q-tips is on the decline and less and less people are starting to use it. And so any web drivers the opposite.
So if you are an individual like myself who had frameworks coded in key you T.P. what the heck are you going to do. You either need to maintain those frameworks in T.P. and have less robust code or you need to transition everything over to sell any and web driver. And if you coded different frameworks you were not insulated from that change. The other factor is that I can actually say where so many drivers actually now more popular than QBP is if you want to look at job trends. I pulled up here dice and search for and web driver just in the Washington D.C. area and you can see that it has 150 positions with solatium of driver. And then also I pulled up dice with QBP in Washington D.C. and you can see that it has 42 positions so so any web job actually is becoming more popular is becoming more relevant. In fact almost 4 to one jobs for so many drivers compared to QBP. So like I said cuchi is dying.
So everybody that has a cute framework or is maintaining an GTP framework at some point they’re either going to need to get rid of it and replace it with selenium web driver or they’re just going to have to maintain it until the technology becomes irrelevant. And so that’s going to be a super painful change to the thousands of tests that exist there to do automated functional testing that are completely unprepared for the changes.