For this in the next section, we'll be drafting automation for the Login Page.
How could we check the page elements, such as the title, the username and the password text box and the login button, still appear on this page?
To find these elements, we can use a few of the matchers we've already seen, along with a few others.
For the Login Page [heading], let's inspect it and you can see it is a heading level 2 (h2).
When we inspect the username textbox, we can see that both the name and the id is “username”. We can see that the label is capital U, “Username”.
Finding Elements
With Capybara and finding elements, it can search by label, id, CSS selector and xpath.
Likewise, the password textbox also has a label.
With buttons you can search by the text — in this case “Login.” We can try searching it by class, we can search by class “radius” or even “sign in”to see if that would work.
Now let's compare it with a test that we have.
require 'spec_helper'
feature 'Login Page: Validate Page Elements' do
background do
visit '/login'
end
scenario 'Displayed Title: Login Page' do
expect(page).to have_css('h2', text: 'Login Page')
end
scenario 'Displayed Textbox: Username' do
expect(page).to have_field('Username')
end
scenario 'Displayed Textbox: Password' do
expect(page).to have_field('Password')
end
scenario 'Displayed Button: Login' do
expect(page).to have_button('Login')
end
end
Let's take a look at the Login Test.
Here we're requiring the spec_helper
.
We're moving the visit
into the background, as before.
Here with the scenario
“Displayed Title” we're doing what we've seen before — expect(page).to
have CSS and then search for all the heading level 2 (h2) tags where the text is “Login Page”.
Searching for this “Displayed Textbox: Username” though, we have something different — expect(page).to
have a field called “Username”, which was the label of the field.
When searching for the “Displayed Textbox: Password” — we expect(page).to
have the field “Password”, which also was the label of the element.
And searching for the button — expect(page).to
have the button “Login” using the text that appeared on the button.
Now that I've demonstrated how we can tell that these elements are actually on the page, let's see what happens if we enter an incorrect username or password.
Let's say we enter into the username, “TJ Maher” and in terms of password, “wrong password” and hit Login. You can see that the message we get is “Your username is invalid!”.
Once we inspect it, we can see that this data-alert
has an id of “flash”, and a class of “flash error”, otherwise known as div#flash.flash.error
.
Let's see if that's something we'd use in our test — this feature
will be a bit more complex.
feature 'Login Page: Invalid Credentials Display Alert to User' do
background do
visit '/login'
end
scenario 'tjmaher / wrong_password: Your username is invalid!' do
error_message = 'Your username is invalid!'
fill_in('Username', with: 'tjmaher')
fill_in('Password', with: 'wrong_password')
click_button('Login')
expect(page).to have_content(error_message) #Is message on page?
end
scenario 'tomsmith / wrong_password: Your password is invalid!' do
error_message = 'Your password is invalid!'
fill_in('Username', with: 'tomsmith')
fill_in('Password', with: 'wrong_password')
click_button('Login')
expect(page).to have_css('div.flash', text: error_message) #Is message in alertbox?
end
end
Let's test that with a Login Page, that invalid credentials can display an alert to the user.
And let's have our first scenario
entering “tjmaher” and “wrong password”, checking that “Your password is invalid!”
Let's create a variable called “error_message” and put that alert we were saying, “Your username is invalid!” as a String, just for readability's sake, when we reference it later.
In order to enter text into fields, we can use the fill_in
method.
We can fill_in
using the field label “Username” with “tjmaher”.
Then we fill_in
using the password label, the field using “wrong password”.
Then we can click the button with the text “Login” and expect(page).to
have content of the “error_message”. This will check that the message is somewhere on the page.
Okay. That's not really specific enough.
With the next test scenario, let's use the combination of “tomsmith” [the correct username] as the username with the “wrong password” as the password.
Let's enter “tomsmith” as a username and “wrong password” as the password. Clicking the login button, we can see the message, "Your password is invalid!" Okay, that's really bad security bug.
Note about Error Messages
You should not be telling the user what they actually failed, whether it's the username or the password. With this app, since it's just a test app, I can let it slide. But you should not have 2 different error messages — one if it's the username that's at fault and one if the password is at fault.
With this, we're distinctly looking for a flash message and checking to see if it contains the text.
Let's see what happens if we enter the valid credentials into the Login Page.
Username, “tomsmith”. For the password, let's copy “SuperSecretPassword!” and paste it and hit the Login button.
Here we can see there's a new message, " You logged into a secure area! " And there's a new heading called “Secure Area”.
If we inspect it, we can see it's a heading level 2.
feature 'Login Page: Valid Credentials Login to Secure Area' do
background do
visit '/login'
end
scenario 'tomsmith / SuperSecretPassword!' do
fill_in('Username', with: 'tomsmith')
fill_in('Password', with: 'SuperSecretPassword!')
click_button('Login')
expect(page).to have_css('h2', text: 'Secure Area')
end
end
So, when we write the test:
Let's run the test and see what happens.
Okay. With bundler, let's execute the RSpec test, which is contained in the spec folder, the features sub folder, and this is test 03, hit tab to tab complete and hit return
bundle exec rspec spec/features/03_login_spec.rb
And all 4 tests have been running and have passed.
In the next section, let's develop some tests for the Secure Area.
Quiz
The quiz for this chapter can be found in section 4.2