Transcripted Summary
We've talked a little bit about test cases.
We've mentioned that there is a Test Cases section in a test suite file. We mentioned that each section within a test case file or a test suite file is denoted by 3 asterisks, a space, the name of the section, a space, and 3 asterisks.
It's also left justified meaning it's all the way to the left. There are no spaces in between these.
As I mentioned before, spacing is very important with Robot Framework.
Robot Framework only knows a section includes Test Cases if the section heading is set up exactly like I show it here.
The same is true for the Setting section and to other sections. One of those was the Keywords section we talked about in the last chapter. Another that we haven't talked about yet is called the Variables section.
# Robot Test Flow
In the test case I have in front of me from exercise-05, called first-test-case.robot, you'll notice I only have two sections here.
# Example Code - first-test-case.robot
*** Settings ***
Library OperatingSystem
Library SeleniumLibrary
*** Test Cases ***
Check invoice manager page
Open Browser http://34.225.240.91/ chrome
#Verify that the text "Invoice Manager" is on the front page
I wanted to use this simple example to talk about test cases and exactly what's going on here. You'll notice in other test files we have all of the other sections involved.
The actual flow of how one of these files works is this.
The first thing to happen is the variable section is loaded. We don't have a variable section. If we did it might look something like this.
So, we might have a variable section down here.
This is the first section that's loaded and that happens first because the variables that we create there (and keep in mind we haven't talked about variables yet we will very shortly), but the variables have to be defined so that the setting section can use them.
First, Variables happens
Second, Settings happens
Third, Test Cases happens
The Keywords section doesn't actually get run until a keyword defined in the keyword section is used within a test case.
Test cases are run from top to bottom, meaning the first test case at the top of the test cases section runs first.
The next one runs second and so on. The steps in a test case run from top to bottom.
This example is about learning to write a test case and adding steps to it. Like I've mentioned before, each of these exercises has a README file.
The README talks about the objectives for this particular section.
You can read them there in case it's easier for you to understand that way.
It's also got a challenge. So the challenge that we'll have here is to verify that the text âInvoice Managerâ is on the first page of the application.
We've shown this application before, but this is what it looks like.
It's a pretty simple invoicing application.
The Invoices page is here, which lists invoices. The Add Invoice page is here where you can add an invoice.
All this test case is going to do, when you're done with it. is to verify that âInvoice Managerâ is on the page.
Let's go make sure just in a manual way; that it actually is as kind of a sanity check. Yup, and there it is. âInvoice Managerâ, that's the text we're looking for on this page in this test case.
So, all this test will do is open up the browser, go to the URL and look for âInvoice Managerâ on that page.
That's your challenge. You'll do those steps here.
You've noticed a couple things by now; one is that I may have different colors in my test case than you do.
There's some really nice plugins for VS Code, for Atom, and for a number of other IDEs for Robot Framework.
If you're using a different text editor, you may want to go see if there's some type of plugin or add-on that will highlight the test case for you. The one that I'm using in VS Code is called robotframework and I'm using version 0.1.3.
The version shouldn't matter.
You'll also notice that I've got a green section here and the reason that the plugin is highlighting this as green is because this line is what's called a âcommentâ.
The pound sign (#) is used to say, "Don't execute anything after this line."
Comments are used in programming to make sure that we can add contextual information to our code. We'll do the same with our Robot Framework tests.
You can also stub out pseudo code for what's supposed to happen, which is what I'm doing here. I'm saying, "Hey, verify that the text âInvoice Manager` is on the front page." How you do that is up to you.
So, once again, you know you can cheat if you want to by looking at the first-test-case.answer.robot, but I'll encourage you not to.
Now, pause the video and go verify that the text âInvoice Managerâ is on the front page.
You'll notice when you run this the first time, it won't pass, but your work will make it pass. Rather, this test case will pass, but it won't be verifying anything.
We want to make sure that it verifies that we're on the manager page.
Spoiler Alert
If you've done that exercise, now take a look at my answer to this. It's very similar to what you had before.
We've got an open browser call and then the only thing that I really added of value was Page Should Contain and then âInvoice Managerâ.
# Example Code - first-test-case.answer.robot
*** Settings ***
Library OperatingSystem
Library SeleniumLibrary
*** Test Cases ***
Check invoice manager page
Comment Checking that we're on the invoice manager page
Open Browser http://34.225.240.91/ chrome
Page Should Contain Invoice Manager
Page Should Contain is a keyword that we found in the SeleniumLibrary.
Remember we looked up the SeleniumLibrary to find keywords in it.
If you want to know how to find specific keywords, I'm not really sure how to tell you. It's kind of like when they taught you how to look up things in a library or how to do proper keyword creation. You've got to kind of brainstorm it a little bit and think through it.
Page should contain, browser should contain, should be in...
The word âshouldâ is usually associated with some of these keywords which assert something or make sure that something works or does a validation or verification point. So âshouldâ would be in there for those.
It's going to be a little tricky to learn the language of each particular library, but you'll be able to figure it out with a little bit of time.
Worst case read through the keywords until you see something that looks like it should work and then try it. See what happens.
# Quick Recap
So now you've been able to create a test case and run it. You understand how a test case runs that it runs from top to bottom.
You understand which sections can be in a Test Case file â Settings, Test Cases, Keywords and Variables.
And you know the order of these as well in terms of how they execute and when they execute.
