Framework Layout

Something that often seems to get overlooked when designing test automation frameworks is how easy it is for other people to pick up the framework and write tests with it. The harder something is to work with, the slower the automation process will be.

Making a framework where it is easy to discover everything available to use has become very important to me. I now field less questions about “hey, is there a class that represents the change password page?”, and have more time to talk about test design philosophy and good practices.

To make a framework easy to discover is a relatively straightforward process. The current way I do this is to create classes that represent different concepts on the framework. While this can vary from framework to framework, the core concepts that are included in everything I create are:

• Framework
• Pages
• Workflows

Framework

The framework class is our jumping-in point.  Almost every action that a test writer can do will start with calling the framework.  Everything else is contained within this class.  When working with a web portal, I usually instantiate this as the variable “portal”.  You could call this whatever you like though, there’s a lot of things that make sense.  The specific product name would also be a great choice.

Pages

All of our page objects are instantiated and accessible through this class.  It keeps all the pages in one neat place, and allows the test writer to locate all of the pages that are available.

This is such a simple quality of life improvement that will make it so much easier for your test writers to find things on their own.  Do not underestimate how important being able to find things quickly is!

Workflows

Workflows are processes that are larger than the scope of a single page.  They allow us to combine multiple pages and areas of the framework into a single method call.  This reduces the amount of repeated code that exists for common processes.  A good example of this is a Workflow method that I typically name

registerUserAndGetToDashboard

You’re probably familiar with this kind of method.  It’s a “just get through all this stuff please” method.  What it contains depends on the exact structure of the web portal I’m working on, but it typically has these steps in it:

• Register a user
• Accept the terms and conditions (yes, this is a separate step where I work)
• Skip through the welcome/tutorial pages
• Check that we end up on the dashboard (the logged in user’s homepage)

All the Workflow does is utilise the page objects within the framework to carry out a series of actions that a single page object would not (and should not!) be capable of doing on its own.  I’ve called these “helpers” in the past, but I feel that Workflows is a much more accurate description of what they are.

Notice that we’re just combining actions from different pages here.  There’s really no new interactions.

For the above example, we’re saving a test writer having to call 4 separate page interactions here.  We’re also making it so that the tester doesn’t have to remember the specific order that these actions are taken in.  This saves both them and I a lot of time when it comes to debugging tests and trying to figure out where things are going wrong.  Are they using the workflow?  If they are, it’s probably a genuine issue rather than them not entirely understanding how you’re meant to combine those individual actions.