Basic Capybara-Gauge: Analyzing The-Internet

Basic Capybara-Gauge: Analyzing The-Internet

For the past year, my job at work has been to create an automation framework that monitors daily our web-based application, putting it through its paces. This project will be showcasing tools and technologies used to compose the framework, but most importantly, the thought process analyzing the site to determine what to test.

Our application under test for this project will be an old favorite of mine: The-Internet, created by Dave Haeffner, author of the SeleniumGuidebook.com -- which comes in C#, Java, JavaScript, Python, and Ruby editions -- and the very helpful blog ElementalSelenium.com.

The tools we will be using:

• ThoughtWorks Gauge, to set up the tests in a human readable fashion
• Capybara, to handle interaction between the tests and the browser
• Ruby, the programming language of the framework
• Bundler, to help manage Ruby's gem files

Why this toolset?

Capybara was chosen as a DSL (domain specific language) since it paired well with Ruby, the language we were already at my workplace, using to spin up AWS instances with Chef, and Gauge, the test framework that was also already being used. Even though I am more used to Selenium WebDriver + Java, this toolset is perfectly fine. As an automation engineer, I am toolset agnostic. What matters more that what you use to test is how you are testing the product.

Analyzing The-Internet

With The-Internet ( Github ) we will be focusing on the Login Page at https://the-internet.herokuapp.com/login. Reviewing the two page site you can see:

Login Page:

• Verify the heading is: "Login Page"
• Verify the subheading contains: "This is where you can log into the secure area"
• Keeping the username and password blank -- or entering invalid usernames and /or passwords -- and hitting the login button all trigger an alert: "Your username is invalid". 
• Entering valid credentials, username and password "tomsmith" and "SuperSecretPassword!" logs you into the Secure Area, after which on the "Secure Area" you get the message: "You are logged into a secure area". 

Secure Site:

• See the heading is "Secure Area".
• See the subheading is "Welcome to the Secure Area. When you are done click logout below"
• Selecting the [LOGOUT] button returns you to the "Login Page", after which you get the message "You are logged out of the secure area".

... When you perform a successful action, an alert is shown, in Green.
... When you perform an unsuccessful action, an error alert is shown, in Red.

The most important functionality to be tested is whether a user and successfully log into and out of the site. If we pull that into a section we can call "Authorization", and spell out exactly which page we are on, we get the following test scripts:

Authorization: Successfully log into and out of the secure area

• LOGIN PAGE: Log into the site using username and password: "tomsmith" and "SuperSecretPassword!"
• SECURE AREA: Verify alert received: "You are logged into a secure area"
• SECURE AREA: Log out of the secure area.
• LOGIN PAGE: Verify alert received: "You are logged out of the secure area"

Authorization: Verify user cannot login with incorrect passwords

• LOGIN PAGE: Log into the site using username and password: "tomsmith" and "incorrect password".
• LOGIN PAGE: Verify alert error received: "Your username is invalid!"

Authorization: Verify alert error is shown when entering a blank user name and password.

• LOGIN PAGE: Log into the site using username and password: " " and " ".
• LOGIN PAGE: Verify alert error received: "Your username is invalid!"

... With these test scripts, we have modeled the exact behavior of the website. We haven't mentioned anything about toolsets or programming languages. What we have done is created a test script we can use verbatim as part of Gauge's specification files.

Note that we don't specifically call out that we are testing that the username and password textbox exists, or that the Login button is or is not there. For these tests, we are modeling actions the user can do.

Rounding out the site, we can also create test scripts for elements not covered above:

Login Page: Verify basic page elements are listed

• LOGIN PAGE: Verify heading: "Login Page"
• LOGIN PAGE: Verify subheading: "This is where you can log into the secure area"
• LOGIN PAGE: Verify label: "Username"
• LOGIN PAGE: Verify label: "Password"

Secure Area:

• AUTHORIZATION: Log into the site using proper credentials.
• SECURE AREA: Verify heading: "Secure Area"
• SECURE AREA: Verify subheading: "Welcome to the Secure Area. When you are done click logout below"

... It gets tiring explicitly listing out the proper credentials each and every time. We are testing the secure area, not explicitly entering data into the username and password textbox, so let's leave out explicitly naming we are using "tomsmith" and the "SuperSecretPassword!".

We now have three good test specifications, with detailed test steps:

• Authorization, which has three test scenarios: Inputing successful credentials, blank credentials, and incorrect credentials. 
• Login Page, which tests the basic elements on that page.
• Secure Area, which tests the basic elements on that page.

Next week, we will create a Gauge + Capybara project, and add the above to the SPEC section! Happy Testing!

Basic Capybara-Gauge:

• Part One: Analyzing The-Internet
• Part Two: Setup Ruby Environment
• Part Three: Setup Capybara to Test Opening Chrome
• Part Four: Add Option For Chrome Headless
• Part Five: Add Test Steps and Spec Implementations
• Part Six: Setup Chrome and ChromeDriver Logging
• Part Seven: Rubocop Code Review
• Source Code: https://github.com/tjmaher/capybara-gauge

-T.J. Maher
Sr. QA Engineer, Software Engineer in Test
Meetup Organizer, Ministry of Testing - Boston

Twitter | YouTube | LinkedIn | Articles