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 are going through the process of running the 2nd automation test.
Selenium Tutorial – Running the 2nd Automation Test
So we finally finished writing the test. Let’s have some fun and actually run this test. I’m going to come up here and select to run this test. Obviously this is Visual Studio and selenium web driver if you like doing a different automation framework and a different programming language you will just run it as normal for your programming language. So fantastic.
The test succeeded. As expected you can see that by the green check marker. Now one other step that I like to do before actually calling my test done is that is to make sure that it’s actually failing. I consider that just as equally as important as making sure that the tests pass passes if not more. Because if you’re getting false positives in regards to the passing that’s really bad because you’re missing bugs that should be recorded in the application.
So what I’m going to do is I’m actually going to execute this test in debug mode. I’m going to come up here and I’m going to click debug and also notice my breakpoint on line 37 my Visual Studio is going to stop at that point and then I’m going to mess with a graphical user interface of the application to make sure that the test actually fails and cross my fingers and hope that it actually does.
Fantastic so we stopped here and I can go back to the page and actually rather than being here what I can do is just go back to courses that ultimate Q8 that can. So now I’ve redirected the page to the wrong location. And in theory, it should not pass.
I’m going to go ahead and step into this method. Because there’s something that I wanted to change here and that was the time span for how long we’re going to wait for the loading icon. I’m going to decrease that to three seconds.
So there’ll be no way for the whole 30 seconds because it’s unnecessary.
I’m going to step over all of this is going to wait for three seconds for the element to be visible. It’s not going to be found. You can see that the web drive or time out exception was thrown. And now I’m going to return false and when we return false our assertion is going to fail. Then when I finish the execution of the test I get a little X over here and that little X when I expand that is going to tell me that the course did not open successfully and that’s a fantastic message that tells me exactly what went wrong and I am very happy with this test.
If you want it to take it a step further and make sure that your test is really stable and I recommend that for a lot of you actually do this with most of my tests if you can actually run this in a loop of about 10 or 20 times and you need to make sure that your test passes 100 percent of the time.
So my framework allows me to do that really easily. I can come up here and put a retry and then I can just specify how many times I want to run this test and then I can easily run it. I hope that your framework allows the same thing. Worst case scenario you can just put this method inside of a loop and run it. But that’s a little bit more painful. But I do strongly recommend that because it helps to flush out any kinds of synchronization issues that you may miss along the way.