What will you learn in this course?

Are you struggling with working with HTML using Selenium WebDriver? Do you know how to easily identify and manipulate an element using Selenium WebDriver? How about performing a drag n’ drop on an element? If not, then these are just a few of the questions that will be answered in this course.

This course is a complete guide on working with web elements in Selenium WebDriver! Once you are finished with this course, you will know how to work with any web elements, anytime, on any web application.

In this course from Ultimate QA, you will learn:

– Basics of HTML

– All the different locator strategies for Selenium WebDriver

– How to identify web elements using Selenium WebDriver

– Master XPath

– Navigation with Selenium WebDriver

– Web element manipulation

– Web element interrogation

– Mouse and keyboard actions with Selenium WebDriver

– Performing actions such as drag n’ drop, drawing, hovering

– Implicit and Explicit waits

– How to properly handle element identification so that your tests are not flaky

– Expected Conditions in Selenium WebDriver

Take This Entire Course for Free

What will you learn in this lecture?

In this video, we will go through the problems with recorded functional tests v2 of the page objects in test automation course.

Selenium Tutorial – Page Objects in Test Automation What are the problems with recorded functional tests v2

So we finally got our recorded test to work. What I’ve also done here for the sake of exemplary purposes is I’ve duplicated these recorded tests.

I literally just copied and pasted them to pretend like we actually have a suite of tests and you can just pretend and imagined with me that we have a suite of 500 recorded tests. Not that it’s possible to maintain a suite of 500 recorded tests but let’s pretend and imagine 500 is a good amount of automated functional test to have. And let’s pretend that we have those tests. And the reason that I want to pretend that we have those tests is because I want to drive a point home in that with a recorded automated functional tests. It is all pure duplication. So if you take a look at the test here compared to the test here compare to this test everything is duplicated and of course I copied everything but there is no other way around it. When you record a test you redo all of your steps and you re-record every single action. Regardless there’s no other way about it. So that’s the point. Now keep that in mind because any single change that we have to make as a result of a change in our application on their test is going to affect all of those tests that directly communicate with that application. So take a look at this test right here test one fix too. What about this test can be affected by the application under test. Something about the application of the test can change that will cause our tests to break.

When you record a test you redo all of your steps and you rerecord every single action. Regardless there’s no other way about it. So that’s the point. Now keep that in mind because any single change that we have to make as a result of a change in our application on their test is going to affect all of those tests that directly communicate with that application. So take a look at this test right here test one fix too. What about this test can be affected by the application under test. Something about the application of the test can change that will cause our tests to break.

Now if you’re looking at this test and it looks OK to you as if you don’t think that there’s anything wrong with test that is completely OK and I actually expect that from you because I’ve been at multiple job situations where people are still using a recording replay to do automated functional testing. Why wouldn’t they. It seems so attractive when they hear a proposition that you can record your test you can record the steps and then have them running within a few minutes and have a bunch of tests recorded within a few minutes. That sounds fantastic. I would love that proposition. But the problem is that when something in the application under test changes everything about the test can break for example are URL can change any of the locators here can change these class names.

They can change these ideas can change of course it’s not as likely but it’s possible the locators can change the world can change even worse the usernames and passwords can change as well.

One of the worst situations to deal with is has data management which is another beast of its own. But imagine trying to navigate from differences to prod. You have to maintain all those usernames and passwords and you can’t do that in a recorded test do URL. What are you going to do when you go from dev to test to prod. Are you going to hard code those you are rails into your scripts. I’ve actually seen that done. I’ve actually been at a workplace where we had about 100 or so automated functional tests recording even though only 30 of them were actually testing any kind of functionality because the other 60 the other 67 percent were just duplication of the first you know 30 percent of the tests because they had scripts for dev test and prod. The scripts were doing the exact same thing. The only difference was that URL. So now imagine how many lines of code you have to maintain the to be able to just look after 30 tests. That’s insane. And so any time any kind of application change happens it will break all of those tests. And as opposed to fixing it in a single place. Now you have to go to three different places for three different scripts to fix your tests.

And that’s the entire point here.

The problem with recording replay is that a single change in your application can drastically affect all of your tests in your application.

As long as they’re touching it because all of your tests are directly touching the application they will all be directly affected by a change in that application. And so that’s why everybody says automated functional tests are brittle because of course they’re brittle when you have a single change that needs to be updated in 500 different instances. Of course you’re going to say that it’s brittle and of course you’re going to throw up your hands in the air and complain.

Pin It on Pinterest

Shares
Share This