In This Course
Did you know that a recent poll revealed that 80% of QA Automation Engineers cannot run more than 100 functional tests daily, with 95% reliability? Furthermore, over 50% of these Automation Engineers struggle to run between 0 – 50 automated functional tests per day!
Functional test automation is a hard job. However, you can make your job much easier by learning a pattern known as the Page Object Pattern. The Page Object Pattern helps to resolve a lot of the problems that other automation techniques cannot. Making your test automation more stable as a result.
This course is designed to teach you how to properly code the Page Object Pattern using Selenium Webdriver with C#.
However, all of the information here is equally applicable to any other functional testing tool because the Page Object Pattern is a universal principle that makes test automation more robust. Similar to other universal concepts such as Don’t Repeat Yourself or Single Responsibility Principle.
Therefore, if you know Object Oriented programming and a different functional automation tool, you can still comfortably follow along with all of the principles and patterns that I lay out in this course.
In this course, you will learn:
– Why other methods such as Record & Replay or Keyword Driven do not work when it comes to test automation
– What the Page Object Pattern is in automation
– Advantages and disadvantages of the Page Objects
– Amazing tips and tricks on how to:
- Implement the Page Objects using Selenium Webdriver
- Improve your Page Objects to follow DRY Principle
- Improve Page Objects to follow SRP Principle
- Create amazing Page Objects for gigantic web pages
In This Lecture
In this video, we will go through on Learning how to evaluate elements at run time.
Selenium Tutorial – Learning how to evaluate elements at run time
So let me clear the string and then try this command again. I think it has to be the zeroth element.
So try again.
Awesome. And that part worked. Now let’s just make sure that the search button is going to work as well. So what I can do is grab this here.
Paste that in the immediate window.
And then run a search and that exit. I’ve got a no such element exception because there is no such element inside of this original storage box that we tried to find.
So that kind of defeated the purpose I shouldn’t have executed that statement. That took me into this code because now you can see I have to stop and restart my test. I should have been executing drivers that find the element commands here to be able to test that out.
But you saw the advantage of that right. So anyways let me fix this problem. I think it’s pretty easy to fix. What I’m going to do is use this code right here to find a search form. OK so now we’re finding the search form just like before and now using the search form we can find the element that has the Submit I.D. button. Let’s de-bug again and see if this works.
So these are the statements that I should be executing in the immediate window. Let’s put that in there put Firefox to the side. Fill out this one with Celine Dion because we already know that works. And then hit enter and now should search out and of course search form doesn’t exist because we’re not in the right context yet. So let me step into the object repository.
There we go.
Let’s try that. And that worked. It returned the element. Let’s see if it’s going to click.
Fantastic. And there it is you guys saw that it worked right. Let me go back. Let me clear this and we can actually finish executing the test. And knowing that it’s going to work. So I’m just going to step over this. It’s going to type this millennium string and then it’s going to click the button.
Fantastic. Everything was successful. We can continue stepping through. And then is going to assert that we’re not on the page which we’re not.
And so now our test is successfully going to finish.
If we go back here you’ll see a little green check mark and the test was successful. So that was another test. The point of me again showing you the immediate window was to show you how to debug element locaters at runtime without needing to rerun your code.
It’s extremely frustrating when I see automation engineers constantly rerunning the tests in order to test their locaters. You don’t need to do that debug it at runtime. Figure out how the locaters supposed to be and then replace it and then your test is going to work. It’ll save you tons of time.