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 what can change about the keyword driven framework of the page objects in test automation course. In this video, we are going through the introduction to the keyword driven testing for the course.
Introduction to Keyword Driven Testing
So that brings us into our next class.
Here you can see I have the keyword driven class and inside of that class we’re gonna have a keyword driven method. What I have to do here for the keyword driven method is to extract out the Webdriver into its own variable so that now it can be utilized by all of our tests.
And you can see that now all our tests are composed of a bunch of keywords also known as methods and they look something like this like Initialize Driver, Go to my Courses page, Click my Account link, type username, type a password, and click login button.
Now, this is the very lowest level of the keyword test. So all I’ve really done is for example, if we want to look at this method, you can see that all it does is literally initialize the driver and that’s very reusable across all of our tests.
Typing a username for example. Typing a username, you can see that it just deals with the username and does a click clear and sending the keys. So basically all of the codes we have before they were just here wrapped with the methods. In fact, let me show you guys side by side a comparison so you can see what we started with and what it looks like.
So, over here on my left side, I have our very original test before we start making it better. And over here on the right hand side you can see I have my keyword driven test.
So you can obviously see right away that the keyword driven test is already much shorter where it has about 18 lines of code versus 25 lines of code for the recorded test which is way better because it is cleaner and obviously much easier to maintain.
Furthermore, you can see that it is even easier to read than the test on the left because there’s an actual method that tell you exactly what they’re doing. And I believe that it is pretty self-explanatory. Like initializing the driver, going to courses page, clicking my account link, and so on and so forth.
So real, awesome, definite improvements. And the greatest thing that we’ve done here is we removed all duplication from all of our tests.
For example, if we need to initialize the driver and rather than have a remote webdriver, firefox webdriver, chrome webdriver, or whatever webdriver. rather than changing every single test that we have to do here on the recorded test side on the left, We just update this method on the right and we just update it right here. And so if you want the chrome driver just change it to chrome driver and every single test just gonna have that change. Change in a single place, update it in our 500 tests. No problem.
Same thing goes to any other method. If for example we want to deal with the username. And anything about the username, whether it’s the email, identifier, or whether it’s the username itself, which obviously can change by going from deep to test for prod.
You somehow have to manage the data. We now can just change the place and now that is going to be reflected in all of our tests.
So definitely that’s the biggest advantage to keyword driven testing in regards to doing recorded tests and of course they save time which gonna really help you to have more stable tests. And again, when changes are coming and you know the data are coming, you have to be prepared. And this is where one of the steps removing duplication is to being prepared for those changes to come.