Basic Capybara-Gauge: Review the Ruby code with Rubocop

This is the seventh part of a series of blog posts. Care to go back to the beginning? 

Tinkering with Ruby only for the past year, Rubocop, a "Ruby static code analyzer and formatter, based on the community Ruby style guide" according to their Github site is both a blessing and a curse for someone new to the language. It is blessing that it is so detailed with output. The curse is that if you are new, it is going to take a lot of random Googling to figure out what all the errors thrown actual mean!

There is a lot of content in the Ruby Style Guide...

What is the Ruby Style Guide?

From the Ruby Style Guide README: "This Ruby style guide recommends best practices so that real-world Ruby programmers can write code that can be maintained by other real-world Ruby programmers. A style guide that reflects real-world usage gets used, while a style guide that holds to an ideal that has been rejected by the people it is supposed to help risks not getting used at all—no matter how good it is. [...]

"There are some areas in which there is no clear consensus in the Ruby community regarding a particular style (like string literal quoting, spacing inside hash literals, dot position in multi-line method chaining, etc.). In such scenarios all popular styles are acknowledged and it's up to you to pick one and apply it consistently".

Basic Capybara-Gauge: Add Chrome and ChromeDriver logging capabilities

This is the sixth part of a series of blog posts. Care to go back to the beginning? 

Want to view JavaScript errors in Chrome? Or see if your Selenium WebDriver instance is throwing any errors? Check out the Logging Preference Capabilities from the Chromium project.

With this article, we will demonstrate how to get these logs set up in your Capybara-Ruby project, and what to add in the spec_helper.rb file we created.

Basic Capybara-Gauge: Setting Up Specs and Step Implementations

This is the fifth part of a series of blog posts. Care to go back to the beginning? 

So far, we have written test specifications to test Dave Haeffner's The-Internet, and we have set up the Gauge-Ruby environment. We managed to get Chrome to run a simple Capybara test, and figured out how to make the test run in Headless Chrome. Our test we created last time...

specs/Navigation/Navigation.spec
# Navigation: Go to The-Internet Login Page

## NAVIGATION: Visit The-Internet
* LOGIN: Visit the Login Page
* LOGIN: Verify the heading is "Login Page"

... For this entry, we will be building upon that, figuring out how to get our Capybara-Gauge framework to execute the following:

Authorization: Validate logging into and out of The-Internet

• Scenario #1: Authorization: Successfully log into and out of the secure area 

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

Basic Capybara-Gauge: Set Up Headless Chrome

This is the fourth part of a series of blog posts. Care to go back to the beginning? 

We've come up with test specs for Dave Haeffner's The-Internet. We've set up a Ruby environment to run the tests, and configured Chrome to open the Login page.

With this entry, we will be activating Chrome in Headless Mode, i.e. running Chrome but without a visual interface, allowing the tests to run faster.

About Headless Chrome

According to Eric Bidelman's article, Getting Started with Headless Chrome, the new option of running Chrome in Headless mode started with Google Chrome version 59, released in May 2017.

Before, you had to use something such as PhantomJS to emulate the Chrome browser if you wanted to run Chrome in a place where the processing power to bring up a visual window would be a waste, such as running it with an automated test script running in a continuous integration environment. Now, it is built right in.

Basic Capybara-Gauge: Setting Up Capybara to Open a Chrome Browser

This is the third part of a series of blog posts. Care to go back to the beginning? 

So far, we have written test specifications to test Dave Haeffner's The-Internet, and we have set up the Gauge-Ruby environment.

Now, we need to set Capybara up to be integrated with the Gauge test framework. 

Basic Capybara-Gauge: Setup Ruby Environments for The-Internet

This is the second part of a series of blog posts. Care to go back to the beginning? 

With the last entry, we analyzed the App Under Test, Dave Haeffner's The-Internet and came up with some test specifications. With this entry, we will be setting up the Ruby environment that will be running the Capybara-Gauge tests.

Although I am developing this project on my Macbook with this example, it is possible to install Ruby, Gauge on a Windows Machine.  See my article, Intro to setting up a BDD framework with VS Code + Gauge + Ruby.

Video Talk: How Software Testers Can Work With Developers

Joe Colantonio, creator of the absolutely awesome software testing podcast TestTalks.com, started in an entire series of Guild Conferences: The Automation Guild, the Testing Guild, and the AI Guild.

Back in January 2018 I was invited to speak as part of the Automation Guild 2018. I gave a talk How to Pass Coding Interview as an Automation Engineer.

I was invited again to speak for Joe's Testing Guild in June 2018. Although automation is all the rage, sucking up most of the oxygen out of any conversation about testing, I decided to give a talk getting back to basics:

How Software Testers Can Work With Developers
June 20, 2018
https://youtu.be/m3nenJ-hAOM

"T.J. Maher has been a software tester for over twenty years since before the concept of Agile software development existed. He believes the relationship between developers and testers should not be one of artist and art critic. Instead, it should be one of a writer and a copyeditor, each working together to create a quality product. T.J. will be sharing his experiences working with developers pre-Agile, working with them on Agile teams, and his insight gained by shifting to automation development".
Enjoy!

And, as always, Happy Testing!

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

Twitter | YouTube | LinkedIn | Articles

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

What software design principles do you use writing UI automation frameworks? Do you use SOLID?

When crafting automation frameworks, do you use SOLID software design principles in your work? If so, could you provide some examples?  

Ever since I've been tasked to create a Capybara + Ruby UI automation framework, I've been reading  books such as Robert "Uncle Bob" C. Martin's Clean Architecture: A Craftman's Guide to Software Structure and Design (2018) and his Agile Software Development, Principles, Patterns, and Practices (2002), trying to glean some insight on how to improve what I am doing.

The SOLID object oriented design principles, a mnemonic created by Michael Feathers based on principles Uncle Bob had collected are a bit beyond me at the moment. Attempting to study about the Single responsibility principle, Open/closed principle, Liskov substitution principle, Interface segregation principle and the Dependency inversion principle, trying to see how I can apply them is giving me a headache.

I fully recommend Angie Jones' webinar, Applying the Pillars of Object Oriented Frameworks to Test Automation for anyone who needs a refresher on Encapsulation, Inheritance, Polymorphic and Abstraction. I wish there was something like this for SOLID design principles!

Here are some of the principles I follow when writing automation frameworks:

DRY

• Don't Repeat Yourself.  Instead of copying-and-pasting code, I factor out commonly used code snippets, placing the block of code into a library I can then reuse. 

YAGNI

• You Ain't Going To Need It. Instead of plotting out every single selector on a page that locates a web element in a user-interface, I focus on just what I need for the current two week sprint. Every single time I try to plan ahead, priorities change, shift, reshape, and by the time I finally get back to the prepwork, everything has changed.

Abstraction

• If there is a Login screen, I create a Login page object, which stores all the locators that interact with the web elements such as the username & password textbox, and the Login button. It also would have a LOGIN method where a test could pass in a username and password and be logged into the System Under Test.

Encapsulation

• Within Page Objects, I declare public methods that then interact with the private variables storing the selectors for the web elements on the page. 

Inheritance

• Are there commonly used elements on the page? I create a Base Page Object which contain commonly used methods that other pages can inherit.

These principles? I find them easy to understand and use. SOLID Principles? Not so much.

Any help that you could give would be much appreciated. I will craft a response blog post from the answers I receive. 

Oh, and don't get me started on how lost I am about the Gang of Four's Design Patterns: Elements of Reusable Object-Oriented Software (1994)!



Happy Testing?

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

Twitter | YouTube | LinkedIn | Articles