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 the previous video, we learned running the 2nd automation test of the page objects in test automation course. In this video, we are going through the process of implementing the IsAt method.
Implementing the IsAt Method
So another we have implemented the student dashboard page. Let’s go ahead and implement that method which is all that we have left to implement in order to finish the test. There is at method. It’s going to tell us that we are actually on the correct page. And that the correct page is actually loaded. So I’m going to utilize my ID in order to create this method. Inside of the user interaction course page my T provides the code template for me and I just need to implement it.
If you guys remember we were going to utilize that expand element that was going to tell us whether we’re the right page or not. Let’s go ahead and check how that looks and the gooey. I want to go back to the previous step and click resume course so that we can see the flow. Notice this loading icon that’s very important because it tells us that we need a synchronization point and that synchronization point has to be a dynamic synchronization point because if you remember when we first started this test it took a little bit longer to load.
I assumed that the application has now probably cached a lot of the information and so it loads much faster. But before that it was a little bit slower so we can’t have a static weight that’s going to be utilized for this test because it’s going to break. So we have to use a dynamic explicit weight and then we’re going to utilize this element to tell us whether we’re on the right page or not.
I’m going to utilize my developer tools of Chrome and then add this element this element tells me that it has an idea called a lesson shelf toggle ideas my favorite locator to utilize with solanine web driver and is the most stable. Therefore that’s what I’m going to use coming back here. What we’re going to need to do is implement a try catch block. So I’m going to write try. And then my idea is going to fill in the rest.
And here I’m going to utilize so many driver’s explicit weight.
So what I’ve done here is I’ve utilized the web driver weight in order to wait until our element is visible. Now I placed in here a variable called expanding element locator. And that’s because rather than hard coding my locator here I’m actually going to use little utilizes for our UI map also known as the object repository. So I’m going to create a property that’s called expanding element locator. My ID already knows that it’s a by Clouse by which is fantastic. And now all I have to do is implement the getter.
And if you remember we’re going to use the ID.
There we go. So I’ve implemented our expanding element locator which just returns an object of type of class by utilizing Dady that we got from Google Chrome. So the reason why I put this in a try catch block is because if this wait times out is going to throw a web drive or timeout exception. Therefore, when the driver timeout exception is thrown. It’s a little bit ugly because it says Web drive or timeout exception has been thrown and I was looking for the solamente.
However, that’s not descriptive enough for me because I prefer to have my assertion tell me exactly what went wrong. So, therefore, I have to utilize this until method cadged a web driver timeout exception and return false. Otherwise, I’m going to return true if the element is present. So now that’s going to that result is going to get passed back to our assertion here. And if it fails I get a nice error message that says the Course is not open successfully rather than an ugly message that says element not found blah blah blah. And sometimes that can be useful. But most of the times I find that it’s not useful and therefore I prefer to avoid it