Writing a UI Automation Framework – Part 1

So I just realized, I keep dancing around the topic of actually building an automation framework.

I’ve written stuff on Dynamic Automation, whether you should write a framework, discussing differences between automation and developer language, and even doing fun stuff using automation.

But not on actually writing a framework.

Welp, today’s the day!

Lately I’ve been training people on how to write automation within a framework, but even that’s… kinda lacking.

The point is to train marketable skills into people, and make them into more powerful testers.

Problem is, nobody can take a proprietary internal tool, and use it at another company.

Instead, they need the skills, also, to understand the underlying code–the “ugly”–that gets hidden by virtue of having a framework.

So that’s my aim with this series–walk through building a simple framework from the ground up, and dip into different technologies. Don’t know how many parts this will end up being, but the journey of a thousand miles begins with the first step right?

By the end of this post, you’ll have the tools prepared for the next step, which is writing a working automated UI test.

Ready? Here we go!

Introduction

The point of a framework is to make you more productive.

Instead of spending the time writing as much code with no constraints, a framework adds constraints–good ones–that let you not have to think as hard about what you’re doing, while giving you a better end product.

It’s kind of like building a jig in woodworking.

If you want to build a project, you could measure, mark and cut everything by hand. That would take time.

But if you start by building a jig for the common or similar parts of the project, then you don’t have to think as much, or spend as much time, working the pieces.

Instead you can just butt the wood up against a thing, make a cut, and you’re done.

The end result is also more consistent work, that “fits together” well.

Better quality. Less maintenance. Quicker output. That’s the point of a framework.

The Three Pillars of Framework Building

Three key factors of a framework are readability, extendability and maintainability. If any of these are missing or wonky, there’s a problem.

Here’s why.

If code is hard to read, then it will be hard to understand, and therefore hard to extend or maintain.

If code is hard to extend, then it won’t be able to grow with the company’s needs. Most times what happens is people will start stapling features on, which makes the code harder to read and maintain. Or they’ll toss the work and rewrite something new.

If code is hard to maintain, then you’ll spend more time fixing the code, and less time actually writing new tests, which is a problem.

To foster strong pillars, we:

Yep, my first framework looked kinda like this. Good times.

• Favor simple code over clever code
• Use minimal or no abbreviations for variables and method names
• Make it simple to make the changes that will happen during the product lifecycle
• Make it lightweight enough that extending it doesn’t require you fight with the framework

The Tools

Ruby

Since we’re starting from scratch, I’ll recommend we use Ruby.

Of all the languages I’ve used to automate, Ruby by far is the easiest to read and write.

These are crucial qualities of any language, as, if you’re spending too much time trying to understand code, or trying to write new code, that’s time not spent thinking about the thing you want to test.

You can make Ruby code nigh-unreadable, as is the case with every language, but the flow of Ruby is better than other languages for what we’re going to do.

What I mean by “flow” is, it’s easier to stay focused on what you’re trying to do, than to focus on the nuances of the language you’re working in.

Ruby’s also a scripting language, which lends itself well to tricks that we’ll talk about later–tricks that you can’t (or can’t easily) do in a compiled language that hollers at you for, say, using methods that don’t exist yet.  Tricks like this help us slam out tests faster, by enabling us to not have to write as much code.

To install: Go to the RubyInstaller site, grab the version appropriate to your computer, and run the package to install Ruby.

Watir

Watir stands for Web Application Testing in Ruby, and handles interacting with webpage elements, along with testing for certain conditions to be true or false. It has its own domain-specific language which we’ll be using a lot.

To install: Go to Start -> Programs -> Ruby (the version you just installed), and open the Ruby Command Prompt. Once at the command prompt, type ‘gem install watir’.

Cucumber

The next technology we’ll be using is Cucumber. Cucumber is tremendously helpful in both having readable tests, but also cutting down on redundancy by using Feature Files (which we’ll cover later), as the test steps.

This means, instead of having manual test steps written over there and the automated test code over here, Cucumber removes that disconnect and redundancy, and allows you to run directly from the test steps themselves. If you haven’t heard of Cucumber by now, you’re in for a treat. 

To install: Go to Start -> Programs -> Ruby (the version you just installed), and open the Ruby Command Prompt. Once at the command prompt, type ‘gem install cucumber’. 

Firebug and Firepath

The browser we’ll be using for this series is Firefox. IE and Chrome (and even Opera) can be used with this toolset, but Firefox is not only a native browser for the webdriver part of the framework, but has some helpful extensions for us to use later.

These are two Firefox extensions which will be handy to use when trying to locate elements on the webpage. Firebug is mainly a developer extension which we won’t use as much, but needs to be installed as a prerequisite to using Firepath, which we will be using.

Firepath allows you to try out some locators to see which ones will work to locate the elements you want to mess with in your test. It uses a language called XPATH which we’ll be using a lot in these tutorials.

To install: Open Firefox and google “Firebug Addon”–the first result should be for getfirebug.com. Installing the addon from there should be straightforward. Next, do another search for “Firepath Addon”–the first result should be for addons.mozilla.org. Installing this addon from there is fairly simple too.

Sublime Text Editor

As far as an editor or IDE goes, I try to pack light. Sometimes I feel like a full IDE is too much, especially for this technology stack. Sublime Text Editor works nicely for getting automation written–it’s basically Notepad on steroids. You don’t have to use it, and I’m not going to be doing anything Sublime-specific in these tutorials, but if you’re interested in trying something new, it’s worth a look.

To install: go to the Sublime Text Editor website, and download the version that you want to use, then run the installer.

Webdriver Element Locator

Finally, this tool will provide good element locators for you quickly, for you to use in your test. Generally, I use this tool first, and then Firepath if this tool can’t find a unique way to identify the element I want.

To install: Open Firefox and search for “webdriver element locator”. The first hit should be for addons.mozilla.org again–install the addon into Firefox from there, and it’ll be available to you to use later.

Next Steps

Ok this is getting kind of long, so I’ll stop here.

Next time we’ll write our first test against the Newtours site, which is an example site used for practicing QTP automation, but we’ll hijack it for our own purposes 🙂 We’ll also start using the tools that have just been installed.

Thanks for reading, and looking forward to sharing the next part with you!

–Fritz