Creating intuitive test automation requires some architecture.
- [Instructor] This is going to be a very exciting unit because you're finally going to get to witness some of the power and flexibility that Robot Framework offers. We're going to take our original script, which is really kind of a mess, and create a more readable script that's more like something you would actually use. I'm first going to provide an overview of why we want to do this, and then I'll give you a preview of the final solution because some of you may just need to see that, and that may be enough for you to be off and running and just do it yourself. For anyone else who needs a more up close tour, I'll continue on and do an introduction to user-defined keywords.
Then we will break up the current original script into keywords. Then we'll move those keywords to a resource file. Then we'll add set up and tear down methods, then we will create page objects to further centralize the logic and locators. And then finally, we'll take a look at Gherkin to see how it might be able to increase the readability of our script. The top three reasons why we don't just want to create the procedural mess that we have in our first script is that we want to improve the readability of the script so that we have a better understanding of the script's intent.
We also want to improve the readability of the test results log, and we want to improve the ability for us to understand and isolate failures when they do happen. We want to improve the reusability. So what we're going to find is that several lines in our original script can be replaced by one line and that one line, in each test case, represents one single place that we could modify, if for some reason that logic changes. So it makes it easier for us to maintain our scripts. And that brings us to the next line here of maintainability.
When we use page objects, all of our locators will be encapsulated in one place. And if for some reason the logic changes of the page that we're testing, we can make a change in one place within that page object file, and that can have the effect of fixing many, many test cases, instead of having to repeat that fix in all of those test cases. So in a minute I'm going to preview the final solution because like I mentioned before, that may be all you need to see to be able to run off and do this yourself. I'm going to focus on looking at the test results, because to me test results are critical.
If you can't easily read your test results and pinpoint failures from them, then the value of your tests suite is dramatically decreased, in my opinion. So we'll compare the results outputs, and we'll examine the failures to see how making a more readable script can have the effect of more readable results. So as you may recall, this is our original script, and at the top of it we're currently referencing the Selenium2 Library. Within the test case, each step is calling a Selenium Library keyword to get its work done. So that's represented by this graphic right here. You can see that I've got my test case file here.
It's talking directly to the Selenium2 Library, which in turn, is interacting with Selenium Webdrivers which drive the browser. The first thing we're going to do in this unit is to break our script up into keywords, and move those keywords into a resources file. So at that point we would have our script, and resources file. And the resources file would then be the only thing talking to the Selenium2 Library. The script no longer needs to talk to the Selenium2 Library. And finally at the end, we're going to wind up with the script, plus keywords, plus page objects. So at the top here you'll see we'll have a script, which is talking to the resources file, which is talking to page objects.
And in its final form, only the page objects are talking to the Selenium2 Library. There's no need for the script or the keyword file to hold a reference to the Selenium2 Library. And as I mentioned before, all of our locators will be encapsulated in our page objects, so that fixing a locator in a given page object could have the side effect of repairing many test cases up here in the script. So this is what our project files footprint is going to look like. We're going to have a tests directory with our script in it. We're going to have an associated resources file called Amazon.Robot, which holds our keywords that the script depends on.
We're also going to have a Common.Robot resource file, which will hold generic things like opening and closing the browser, that really have nothing to do with Amazon. Then, within the resources directory, we'll have a page objects directory, which is a PO directory there. And inside there, we'll have page objects like landing page, top navigation, the search results page, and the product and cart pages, and so on. All of the pages that we interact with in our script will have a respective page object that contains logic and locators. And finally the results directory will have our results.
I believe it's critical to your test automation effort to make your scripts as readable as possible. And you can see here on the top, this is the original script we created. It's talking directly to Selenium Library keywords, and as you scan through it, you can't really get an immediate understanding of the intention of the test case, unless you read through each line and really connect the dots. However the second example at the bottom, you can see we have four lines that make it pretty obvious what's happening. We're going to search for products, we're going to select a product from the search results, add the product to the cart, and attempt to checkout. So you can see that's tremendously more readable.
And as you might expect, a more readable script results in more readable test results. Again you see at the top, if you handed this test result to somebody to analyze, they could glean from the title what the test case tests. But when they look at the steps, they wouldn't really have any immediate idea what's happening where. However down at the bottom, again, you see that our simplified test steps make the test result file much easier to read. And while on the top file, every single keyword you can see is coming from the Selenium2 Library, in the bottom file you notice that the first and the last steps are coming from the common keyword file.
And the middle steps are coming from our Amazon keyword file. When it comes down to interpreting failures, again, the image at the top, you can see that the final keyword failed, and you can tell that it's waiting for something to appear on a page, but when you read a few lines before that, you really lack context about what led up to this failure, and also notice that the browser never closed after the test failed. If you go back and look at our passing result, you'll see that this keyword right here is the one that failed, and the test case was supposed to continue on through all these steps, including closing the browser at the end.
However since the closed browser is just a normal test step, when I encounter this exception right here, Robot Framework bails out and skips the rest of the steps. Therefore the browser never gets closed. However down here in the second image, when you scan down to this first failed keyword here, you can see that I have it expanded to see what else is inside there, you can tell right away what failed here at the top level, because it says, select a product from the search results. Well, apparently we failed to select a product from search results. And if you look backwards a couple of steps, you can pretty much tell what's going on. We started our test, we did a search for products, and then we tried to select one of those products.
If you expand this keyword just a little bit, you'll see that clicking on the product link actually worked, but it was when we tried to verify that that product page loaded is when things failed. So right off the bat, our ability to understand precisely where things failed has increased dramatically compared to this to top image here.
- What's a test automation framework?
- Robot Framework vs. Selenium
- Creating and running your first script
- Options for running scripts, including PyCharm and Jenkins
- Making a script more readable
- Using variables to centralize data
- Incorporating the Page Object Model
- Robot Framework libraries