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 keyword driven testing of the page objects in test automation course. In this video, we are going to fix the problems with recorded functional tests for the course.
What can we do to fix the problems with recorded functional tests?
Looking at this record a test in front of you and just all of the lines of code and the constant duplication, I bet you already know the solution.
I know, I bet you know that all you have to do is take the duplicated lines of code and stick them inside of Method. If you place them inside of methods they will allow us to reuse our code over and over again.
So if you wanted to type in a username with these three lines of code rather than copying and pasting them from test to test. Now we just place them inside of a method. If you wanted to type in a password rather than constantly copying and pasting these three lines of code we just place them inside of a method and obviously that’s the purpose of methods. They allow us to reuse our code and decrease maintenance because when something changes like a locator for that method all we have to do is go to a single place and update there. And now all of our tests are going to be easily updated.
But all that said and knowing that you need to replace everything with methods, that kind of brings us to our next level of automated functional testing. And that’s known as keyword driven testing.
Basically, keyword driven testing is utilizing a bunch of methods also known as keywords that we call in a specific order to perform a bunch of actions. Let me cover that more in the next section