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
Understanding the BaseTest and CoursesPage
Now let me walk you guys through the test and so that you better understand everything that’s going on along the way. I’ll point out to you all of the benefits of the page object model on how it helps you to have a more stable test. And then we’re going to wrap things up where I’m going to add another test live so that you can actually see what’s going on and how to further enhance your tests utilizing the page object model. So we obviously have our class. Now, this class is not named appropriately. Normally you can name it based on your functionality or a feature that you’re testing. And each of our classes inherits from a base test class. If I navigate to a base test class what it does is two very simple actions. If there’s a
Normally you can name it based on your functionality or a feature that you’re testing. And each of our classes inherits from a base test class. If I navigate to a base test class what it does is two very simple actions. If there’s a setup and tear down. So in the set up what it’s going to do is initialize a Firefox’s driver with a maximized window state for every single test and then to tear down a car driver is not equal to all we’re going to quit the driver and that’s it. So for every single test, we’re going to initialize a Firefox driver and then tear it down. That is the beauty of utilizing not only the page object model but classes is that you can remove a bunch of duplicated functionality. So now in the
That is the beauty of utilizing not only the page object model but classes is that you can remove a bunch of duplicated functionality. So now in the future, if I needed to create another class I can simply inherit from the base test and I would automatically get the instantiation of the driver and the tear down of the driver out of the box without having to write a single line of code.
Obviously the beauty of inheritance now inside of the test. What goes on is actually pretty simple. All we do is create a new page. You usually name the page according to the actual web page and you may be looking at. So when we were interacting with the Course page I created a course page I would recommend that a good pattern for utilizing the page object pattern is every single HVM page that you interact with and deserves its own class. So when I instantiate this new page I obviously pass it the driver that we created in our base test and the driver gets assigned to the courses page variable. And now we can utilize it throughout our page for whatever purposes we need. For example like the goto
And now we can utilize it throughout our page for whatever purposes we need. For example like the goto method. The go to method will navigate directly to this URL and Link is going to click the sign. And link and then return us a student log in page. You guys can see how each of the methods encapsulates the functionality that directly interacts with the web page, therefore, saving us from any possible changes.
Because if I needed to change for example handling this sign in the link the only place that I would need to change it is up here where the sign in link is identified and by the way you guys can see up here that I also have. Well, I only have one element that I have my elements. This is we can refer to it as a UI map in my all my elements will be stored in these properties that retrieve me the element with its identifier.
And whenever anything changes all I have to do is update identifier right here.
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