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 writing the first functional test for the large page of the page objects in test automation course. In this video, we will go through the Understanding why having a complex HTML page is a problem for the course.
Understanding why having a complex HTML page is a problem
Right here you can see the automation practice page. This is the ultimate slash automation link. This is kind of the home page to take you to different scenarios in regards to automated functional testing. I’m going to constantly keep expanding upon this page so that you have many kind of different scenarios to automate and practice as we go through our lessons. For now there’s only two but we’re going. In this case we’re going to deal with this big page with many elements. So if I can click this link and it will take me to that second your rail that I showed you or you can obviously just navigate directly to this you RL and then look at this page.
Now this is the complicated page with many web elements that I’m showing you. So you can see it has a bunch of different sections it has many buttons. It has many different kind of social media buttons and it has a section of random stuff that has different kinds of things like Serj boxes contact boxes it has side bars it has a log in boxes it has a carousel to navigate through different kinds of posts. It has toggles more contact boxes and so on and so forth.
Obviously this is not a real page that utilize this is just something that I quickly created for you to be able to practice your functional test automation on. But you can see how many elements it has and how many different kinds of methods can be possible for this automation page.
In fact for me to better example of ify how this page would log if we were to write it let’s go ahead and do kind of a mock up of this page. Just so you can see how gigantic It can get. So take a look here what I’ve done is on the left hand side I’ve started a construction of our sample complicated page class that we would code for our functional test. And on the right hand side I have the actual HDMI page so that we can look at it while we pretend to ride out the you and I’ll diagram for this.
So if we just start at the section of buttons we can see that there are 12 different buttons that we can press.
So obviously we need locators for each of those buttons.
OK. So there are all the elements of the buttons. Let’s do the social media section. OK so I’m just going to leave it like this. Pretend that these are actually different properties. Twitter one two three four five Facebook button one two three four five just don’t feel like wasting your time with expanding all of this. So we’ve gotten through two sections than there are more sections here of random stuff.
So you can see how gigantic This page is already starting to get. These are just all of the elements then all of these elements are going to have methods. Right like clicking on getting the text sending text inside of web elements clicking the buttons searching so on and so forth is going to have a ton of methods. So probably what you’re going to end up with is a cloud that’s several hundred if not a thousand lines long and you can probably guess that that is a giant problem to have such a monolithic class having so many things to maintain.
So that’s the problem. And the other problem is that technically if you’re following the page object model this on the right is a single page. So it does belong in a single page class. So if we were following the page object model we would be doing the correct thing. However after a little bit of time as you progress this class would become a mass. You would need a method a way to clean it up make it easier to read easier to maintain and easier to utilizing all of your tests
Nikolay Advolodkin is a self-driven SDET on a lifelong mission to create profound change in the IT world and ultimately leave a legacy for his loved ones, community, and the world at large. Today, he serves as the CEO and Test Automation Instructor at UltimateQA.com and contributes informative articles to leading test automaton websites like SimpleProgrammer.com and TechBeacon.com