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

Free Video Course

In This Lecture

In the previous video, we learned the advantages and disadvantages of keyword driven test of the page objects in test automation course. In this video, we are going to discuss what can change about the keyword driven framework for the course.

What can change about the Keyword Driven Framework

 

So the question that I want to post to you now is this. Do you believe that with the keyword driven approach that these tests have illuminated enough possible sources of change to actually be stable and not be classified as brutal again. Sadly I don’t think so. I believe that keywords are given to us although they are an amazing step up from a record to us. They still have a ton of problems that will cause you to spend a lot of time debugging. And not be able to maintain your automation frameworks. I remember many years ago when I was writing Cambridge given to us it was actually utilizing QBP.

I remember how hard over time we had to automate tests utilizing the keywords. Or in the framework can be we’re doing a pretty good job. We had a good team of really smart people writing key driven tests because we thought that that’s the best approach and we still would spend weeks trying to make a single test pass.

Granted we were doing a lot of things wrong but again we were all utilizing that keyboard-driven approach. And we were wondering why is this so hard. Why is our automation so brittle that it takes us weeks to put out an automated functional to us. It was really sad but it is a good lesson because we thought that was the right way. We thought that this is the way that it should be done without realizing it. And that’s what I want to help you guys here with today to be able to understand that there are better ways regardless.

So the first main issue that I see with the coverage given to us is that they are still wet. We are still writing everything twice. They’re not dry and they don’t follow the DRY principle. For example, take a look at test number one lines 19 and 20. How does two methods along even with this verification they are repeated here and test two. And they’ve also repeated in tests three in fact almost this entire test is of repetition in each of the tests. And yes, of course, I know that these tests are literally duplicates because I just copied and pasted them.

But you can see how from scenario to Scenario. A lot of steps can still be repeated. Right because our steps were just logging into an application. That’s one of the very basic features of every application. And we can take it into many different directions from there. We can start logging in and then validating that a video opens we can start logging in. And then validating that we can select the video we can go invalidate that we can go through an entire course.

There are many different kinds of functionalities but they all have this log in functionality in common and it is all being repeated through all of our tests. So whenever we make any kinds of changes, for example, a synchronization change because our application is now slower or for whatever reason maybe it’s we introduced a bug that’s making our application slower. So now for example, if we have to deal with the synchronization point we might need to come here and replace this implicit wait with an explicit way to be able to better handle the loading of the application.

And so now we have to apply this change to all of our five hundred tests as opposed to a single place. I actually had that happen to me recently where I had a bunch of Turse I think a few thousand times that were running. Then when I look back at the results I saw that there were about 100000 that had actually failed. It was really interesting to me that that failed because I was like what’s going on. And then when I further analyzed why the tests failed it was actually because our application.

I think had gotten a little bit slower. And so what had happened was the test was running too fast for the application. And so now it was failing because there was a bad synchronization point and saw what I had to do was go away and of the synchronization point and then that fixed my 100 Tests. The beauty of it was that I fixed the synchronization pointed at a single place rather than all of these other places and all of the tests. And that made my fix really quick and really easy and then the test passed right after I finished running them.

But it does happen synchronization issues happen all the time. And my point is that you need to be prepared for those changes as good as you can. And unfortunately, the keywords in the framework approach doesn’t really prepare us as well as it can. Some other issues that can actually occur with a keyword driven framework that will break all of your tests our flow changes.

The beauty of it was that I fixed the synchronization pointed at a single place rather than all of these other places and all of the tests. And that made my fix really quick and really easy and then the test passed right after I finished running them. But it does happen synchronization issues happen all the time. And my point is that you need to be prepared for those changes as good as you can. And unfortunately, the keywords in the framework approach doesn’t really prepare us as well as it can. Some other issues that can actually occur with a keyword driven framework that will break all of your tests our flow changes.

Right so here in my in this current flow I’m logging in. But I am logging in with a browser in a standard maximum window size. What if now I needed a test that logs in with a browser in half size. Would if I knew to have the logs in with a browser in a mobile window write that functionality is different and it needs to be handled differently. And so what am I going to do am I going to create a completely new keyboard to be able to log in in a different kind of mode. Or should I have one method that handles both of the situations depending on which situation you’re in.

I would argue that the method is a better approach because you decrease your duplication of code. And all of the methods and now you’re just stuck with one method as opposed to two methods that you need to maintain. But the final piece of the puzzle that can actually break a bunch of our automated functional tests is a change to our actual driver.

Yeah, that’s right. Selenium can disappear at some point it may no longer be relevant and you might need to replace it. So all of our tests that are using these find elements all of these hard coded methods for selenium web driver they’re going to break and you’re going to need to replace that with an entirely new driver. And if you don’t believe me that the driver can change. Take a look at Google Trends with me for a second. I’m sure that a lot of you guys remember QBP right.

And here in Google Trends what I did have I just compared the popularity of cuchi versus selenium web driver and down here you can see GGP versus solanine web drive or searches over time. So take a look back in 2011 TGP used to be really popular and selenium web driver did it. And now over time that is actually reverse where so many drivers are becoming more popular than GTP. Yes, those are Google search trends. But what it should also tell you is that Q-tips is on the decline and less and less people are starting to use it. And so any web drivers the opposite.

So if you are an individual like myself who had frameworks coded in key you T.P. what the heck are you going to do? You either need to maintain those frameworks in T.P. And have less robust code or you need to transition everything over to sell any and web driver. And if you coded different frameworks you were not insulated from that change.

The other factor is that I can actually say. Where so many drivers actually now more popular than QBP is if you want to look at job trends. I pulled up here dice and search for and web driver just in the Washington D.C. area. You can see that it has 150 positions with solatium of driver. Then also I pulled up dice with QBP in Washington D.C. And you can see that it has 42 positions. So so any web job actually is becoming more popular is becoming more relevant. In fact, almost 4 to one jobs for so many drivers compared to QBP. So like I said cuchi is dying.

So everybody that has a cute framework or is maintaining a GTP framework at. Some point they’re either going to need to get rid of it and replace it with selenium web driver. Or they’re just going to have to maintain it until the technology becomes irrelevant. And so that’s going to be a super painful change to the thousands of tests that exist there to do automated functional testing that are completely unprepared for the changes.

0 Shares
Tweet
Share
Share