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 the previous video, we learned the recording automation test using selenium builder of the page objects in test automation course. In this video, we will go through the understanding the layout of the solution for the course.
Understanding the layout of the solution.
OK so here we are in Visual Studio and again don’t freak out if you don’t know Visual Studio C#. All of these concepts apply to whatever bindings of web drive what you want to be using or whatever bindings of any kind of automation tool you want to be using. These are concepts and ideas for automated software testing not tools specific. So don’t freak out. Let me quickly give you a little bit of a breakdown of what I did here of the lay out so you can better follow and then we’ll will actually dig into needy greedy of the code. So what I tried to do was I named my classes in order of steps logical steps that were going to divide our automation into.
So if you look here in the solution explorer you can see that I divide it into basically five steps and I’m going to go through each one one by one. I wouldn’t normally name my classes like this but I did so just so that they’re perfectly organized so that you have a easy time of following along with me. If you’re looking at the actual code I’m utilizing and unit here so I’m just creating standard and unit test classes. OK. And then we created our original test and then I copied over our original test. We just recorded two other times just so that we can per time like we have a test suite. Not that they’re relevant Marge. But just to have them there for exemplary purposes. So that’s really about it. That’s the organization.
Once we exported out our recording what it produced was a file that looked literally like this. I took all of this code right here. And then I copied it into this method and I called it original recording. So when I hear you guys can actually see our test take a look at it and ingest it looks pretty straightforward right just like a normal recording would look.
One thing that you may notice here is I actually put my username and password into environmental variables of my machine because I don’t want to give you guys that username and password because I don’t want to be everybody to be using my test user for my application. So those are here for me.
If you’re utilizing this code you’re going to need to supply your own test user and you can do that by simply just signing up as I showed you before. So besides that the other thing that you might initially notice is that we have our assertion here but this assertion actually kind of socks because it’s not really an assertion it’s more of a if condition and then if that if condition fails then we’re riding out to the console and that is annoying because if I was to run this overnight or in any kind of way I wouldn’t really have a history of my results. Rather I’ll just have a console outpoured within that console is going to disappear and after that my tests done. So the very first thing that we have to do with this test is actually to clean it up a little bit. And I just replaced this with a single assertion that does the same thing.
But now this assertion is either going to cause my unit tests to pass or fail I’m going to have a history and I’m going to have errors that I can look at after I’m done with running my tests. And you can see up here that I actually put a war on because I had to take one step on this automated test in order to be able to fix it immediately after the recording basic I couldn’t really even use this automated test in its original form after the recording I had to take one initial step to fix it. And I’m not going to count the user name on the password. Putting got into environmental variables because technically if you’re recording this test you don’t really have to replace that data. So I’m not counting that stop I’m only counting replacing the assertion.
So now that we replaced our assertion we actually have our test and I’m calling that test test 1 and we’re going to follow test 1 through the entire process as it evolves through the automation testing logic to become better and better.