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 this video, we will go through some further understanding of the Single Responsibility Principle.
Selenium Tutorial – Further Understanding Single Responsibility Principle
In this next section, I would love to cover with you the Single Responsibility Principle. Single Responsibility Principle is another principle that is extremely important for helping you to further make extremely robust functional test automation between page objects the DRY principle and the Single Responsibility Principle.
I think that you will probably have a 10000 percent or more increase in the ability of your functional test automation at least I believe that that’s the kind of stability that I experienced from my functional tests. So the Single Responsibility Principle is pretty simple.
What it states is that a class should have only a single reason to change the benefits of the Single Responsibility Principle. Is that a change in an unrelated functionality will not break two functionalities or more. What do I mean by that is for example if you have a pizza baking functionality when we change it should not break how the store delivers the pizza. Right. So those two classes should be separate the delivery of the pizza should be independent of the baking of the pizza.
And so the change in the baking functionality should not directly affect the delivery functionality right.
Not only does it make sense for me code perspective. It even makes sense from a logical world perspective because when a pizza is baked that has no impact on how the pizza gets delivered. And so that’s what the single responsibility is making sure that each class has a single responsibility and a single reason to change so that you’re not breaking other classes. Let’s take a look at a few more examples just so you can better understand what I’m talking about.