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 the learning how to evaluate elements at run time of the page objects in test automation course. In this video, we will go through on Debugging the 2nd complex test for the course.
Debugging the 2nd complex test
So here I’ve written another test that does a search functionality and then make sure that the search was executed. I copied over this initial code from Test 3 that goes to the complicated page and then validates that the complicated page has been loaded and copying it over I broke. Which of the principles is obvious and not dry. So up for refactoring in the future anyways so did that and then I wrote a search method that takes in a search term.
So the search method is very simple. It uses the search box to send the keys of some string and the search box is stored in our object repository. And I used XPath to find it by searching for all of the roles called search and then picking the second item on the page. There were three items on the page when I was using developer tools to find it. Then utilizing the search button we click it and perform our search the search button.
I found that by using the ID search submit and I searched inside of the search box that was returned. So once we performed the search then I just did a simple assertion to make sure that we are no longer at the complicated page through the complicated pages not visible. Now this is not the best way to do it.
I would if I was actually writing a test I probably would return a page through the search option and then validate that I’m actually on that right page.
But again my goal is to show you guys concepts and struggles that automation engineers face. So I’m trying to conserve time and let you focus on the most important aspects.
So I just did it in the simplest way possible. Again copying over another assertion possibly another option for implementing the dry principle.
So let’s step through this just to make sure that the code actually works. I’m going to debug up to this point.
And then step through the rest.
I’m going to step inside of this method.
And the one thing I’m going to do here is utilizing the immediate window in my ID. To execute these commands right here to make sure that they work. Rather than using my ID to actually step over these actions and get an error and then have to restart I’m going to use the idea to execute these commands and then figure out if they work or don’t work on the fly.
This is really beneficial because many people will try to step over this and then if something has gone wrong they’ll get an exception and then they need to restart running of their test which is really annoying. So this is something that I’ve seen being done over and over and I want to teach you guys this technique.
Now it’s really easy in Visual Studio. I assume that you can probably do it in most other IDs as well.
Let me show you how to do this. So I’m just going to take this statement right here pull up my immediate window and then I’m going to execute it. If it’s executed right then we should see a search value filled out here. It wasn’t once.
And let’s look at this.
All right so I think the problem was I was looking at this element which is the entire form and I don’t think you can type into this element so rather I’m going to type into this inport which has an ID of type and an ID of value. So let me try to debug that here live. Excellent. Did you see how that worked.
That’s the beauty of this live debugging is that it allows us to figure all this out on the fly. And it’s most common with Element locators. Sometimes I think they’ll going to work in Developer Tools and then when I go to selenium I just you know mess things up everybody makes those mistakes. So I’m going to go back here to the search box and update that.