Transcripted Summary
So, we have two tests now, but they actually have quite a bit of overlap because they're both exercising the same login form, and they have the same locators. And if the application that we're testing changes, we'd have to go to multiple tests and modify each of them. It's a bit annoying and can become really unwieldy very quickly.
Built into Selenium IDE there is a helpful command called the run command.
So, if you come to the documentation on the right-hand side here. There's the table of contents and I'll just click run and it shows the ability to, with the run command, you can run a test case from the current project. So, from within one test you can execute another test.
Let's go ahead and put this into practice to streamline these happy path and sad path login tests.
What we'll do is we will create a new test called “login” and in here is where we'll store the behavior of filling in the login form. Then in each of these tests, we will go ahead and call that test and specify each of the credentials that we want and then assert that the outcome was successful.
Actually, for simplicity, I'll go ahead and just duplicate a test to do this refactoring. So, I'll delete the “login” one I just created and rename this one to “login” and then remove the assertion commands. Now this is the basics of what we need.
I'll go ahead and also use one more command, which is the store command.
If we hop over to the documentation and click store —you can save a target string as a variable for easy reuse. So, we're just taking a string, putting it into something that we can call by name, then well use that as we use the log in command.
What we'll do is we'll come into one of our either invalid or valid tests, and we will go ahead, and we want to keep the assertion, but we want to delete all of the commands before it.
We want to add a few commands — two store commands and a call to “login”.
So, what we want to do is we'll call run(and again there's a reference tab if you want to see it to find out more information) and the name of the test.
We're going to run “login”.
Command: run
Target: login
In order for “login” to work, we want to give it variable information for the username and the password that we're going to use to complete the form.
We're going to store and it takes the text. This is the invalid case, so we'll just do “blah” and we'll store it as “username”, that's the variable name.
Command: store
Target: blah
Value: username
And we'll store “blah” and the variable name is “password”.
Command: store
Target: blah
Value: password
Then if we hop into “login”, we can modify this so that is uses the variable names instead of hard coded string values.
When using a variable in Selenium IDE, you have to specify these wrap characters that go around the variable name for what's called interpolation.
So, to do that it's dollar sign and then curly braces, and within the curly braces you specify the variable name.
So, for username —
Command: type
Target: id=username
Value: ${username}
And then we'll do the same thing for password —
Command: type
Target: id=password
Value: ${password}
Then what we can do now is run this and make sure that it works.
So, if we hop back to the execution pane, we can see that the test ran and it was all green, no failures. And it was successful.
Let's go ahead and modify the valid case to do the same thing.
So, we'll go ahead and delete, delete, delete. Keep the assertion. Then add our commands.
And store, and we're going to store “tomsmith” as username.
Command: store
Target: tomsmith
Value: username
And then we'll store the “SuperSecretPassword!” as password.
Command: store
Target: SuperSecretPassword!
Value: password
Then we'll call run of “login”
Command: run
Target: login
Let's run this to make sure I didn't fat finger anything.
Cool, that all works and you can also see it in the executing pane that it worked.
And we can go into test suites and see that we have our valid and invalid case and the reusable test itself (“login” isn't part of a suite). So, when we want to execute, we would just come into test suites and we can execute the valid and invalid cases.
That's it and if we wanted to make the names more specific, we can say “invalid credentials” and “valid credentials”. So then when we actually read it in the suite, it looks a little bit more correct.
That's test case reuse, and one last thing, let's just make sure we remember to save the project.
