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 about understanding BaseTest and CoursesPage of the page objects in test automation course. In this video, we are going to take a first look at a functional test using the page object model.
First Look at a Functional Test using the Page Object Model
Here we have a test that is utilizing the page object model in order to test the functionality of the application. One more to caution that I’d like to give you guys is that there is numerous implementation of the page object model that I have seen many many different ones and I’m sure there are way more than I have seen. So this is just my attempt at utilizing the page object model to write automated functional tests. It may not be the most optimal way. And so if you have any suggestions that are going to make this better or my page object model better please let me know because I’m always looking to get my tests as good and as stable as possible. And I’m always willing to learn and take more advice. So if you see it and just let me know I’ll be glad to hear it regardless.
This is the page object test that we have been familiar and we’ve been working with throughout this entire series. The very first thing I’d like for you guys to look at is to compare this test in its form to our record a test. So let me pull up a new vertical tab group here and on the right-hand side you obviously see my test utilizing the page object model and on the left-hand side is our final version of the recorded test. This was the fix to the one where we finished implementing everything to actually get the test to run. Look at the difference. This test is about seven lines of code including spaces.
While this test is about twenty-four lines of code with very little I mean yes it includes comments and spaces to look at the difference it’s drastically smaller in size compared to our record test.
Look at the keyword driven test compared to our page object.
The keyword-driven test, of course, was a little bit smaller because it started utilizing methods. But again the keyword driven test is 15 lines in size versus the seven lines in size for the page object model. Now granted that doesn’t say much about the stability of the task a number of lines of code. But what it does say is that our code is much smaller and cleaner. And as you will see it’s even easier to read than the predecessors.
So let me close these now.
Talking about the readability of the test. Take a look at how easy it is to read this test. You create a new course a page utilizing that course that page you’re going to go to that page then utilizing the courses page you’re going to click the sign in link. Then you get a login page using the login page you’re going to log in entering the user and the password that I have stored in my environmental variables. Finally, you’re going to assert that something is true and that something is the student dashboard page is at. How easy is that to understand. You went to the page you could design and link your login and then you’re checking your lobbying at the right page. Again readability and extreme plus for the page object model.
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