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 introduction to the page object pattern of the page objects in test automation course. In this video, we are going to discuss the transition process into page object pattern for the course.
A Transition into Page Object Pattern
So you’re probably asking yourself what is it that you can do to write better functional tests. We’ve covered record and replay which obviously sucks for automated functional testing. We’ve covered keywords different frameworks that expand on record and replay but still have a lot of drawbacks. So what can you do as an automation engineer to actually write really stable tests.
Well, that’s the entire point of this tutorial. The entire point is for me to teach you about the concept known as the page object pattern the page object pattern is an excellent pattern that helps you to resolve many issues that we faced in the keyword driven framework and the recording replay methodology and it helps us to insulate us from change.
So with all that said for the rest of the tutorial what I’m going to do is I’m going to help you to understand the page object pattern. We’re going to look at a bunch of code and how the page object pattern looks there and we’re going to learn how to use the page object pattern to be able to write automated functional tests. Let’s proceed
Hello Nikolay
I recently completed the ‘Selenium Webdriver Complete Course – Build A Framework’ course. I downloaded the Light POM Framework that was developed in the course and have used this in my work. This has worked very well for me. In the course you mentioned that the Light POM Framework has a number of disadvantages:
1. Needs to be refactored to control multiple Browsers (for Cross Browser testing).
2. Needs to be refactored to run in the cloud (e.g. for utilising SourceLabs/BrowserStack).
3. Cannot run in an automation fashion (can’t schedule tests).
4. Cannot be executed externally.
5. Does not leave logs behind.
6. No visual guideline to all the tests that exist and what functionality is covered by the tests.
I am now in a position to want to be able to carry out these kinds of functions.
In the first instance, I need to refactor the Light POM framework to be able to do cross browser testing.
Then, I need to refactor to run in the cloud.
And in future I will no doubt want to cover points 3 to 6 as well.
I would be most grateful if you could provide me with any information/guidelines on the necessary refactoring that will be needed.
Many Thanks
Ranjit.
Always happy to help.
1. Cross browser testing is easy. All you need to do is create a new test for every single browser. In that test, just make sure that you create the appropriate driver that you desire and then use it like normal. For example, new ChromeDriver, new FirefoxDriver and so on…
2. Cloud is also pretty easy. Again, you will just need to return a new RemoteWebDriver() with the appropriate parameters. The test will function like normal.
Hope this helps 🙂
This generally looks like a visual testing task. Are you limited to Selenium only? In case there is an option for you to try something else for this task, you could do that with a visual regression testing tool. Such as Screenster (http://screenster.io/) which is actually an alternative to Selenium for visual/CSS testing tasks.
Screenster is a test automation tool which performs screenshot-based comparison of different versions of your web pages. First it creates a visual baseline for a page, taking a screenshot for each user action. During the next run it takes a new screenshot at each step, compares it with the one from baseline and highlights differences. It also has a number of features for easy maintenance of tests.