The 7 Best Practices for Visual Testing with the Galen Framework

For the past few months, we have been executing our visual testing with the Galen framework. First of all, this should illustrate that we think it is a great framework.

 

For those of you new to the Galen Framework, it is a test framework used for responsive and cross browser visual testing and functional testing. Galen also has Galen Specs its own visual testing language. These are based on the Selenium WebDriver. Galen Specs also contain a JavaScript API that allows you to interact directly with Selenium. These features allow users to run tests in any browser in the cloud and in addition test on real mobile devices as well with Appium Studio.

 

Encouragement to write this article came from a desire to share the best practices that will enable you to overcome some Galen framework challenges.

 

Write Small specs

 

My first recommendation is to create small specs. The reason for this is that with small specs you can always tell what the issue is in case a test failed. With larger, more detailed scenarios a failure can result from any number of errors which makes the investigation and debugging much more difficult.

 

A Galen Spec is a file (.spec postfix) that represents the layout specifications of a specific web component.

 

“Galen Specs Language is quite flexible and gives you the opportunity to express exactly how you want your website to behave on different devices. There are two main parts to a page specs file: object definitions and object specs”

 

http://galenframework.com/docs/reference-galen-spec-language-guide/

 

So how do we define small specs?

 

1. Up to 10 elements (object definitions),
2. No more than 20 rules (object specs).

 

It would be a mistake to try to write a single spec per website page. From my experience, a complex web page should have around 10 specs that fully define it.

 

Work from the top down

 

Start by identifying your main page containers. Then, build a dedicated spec to test the page structure.

 

Usually, the high-level structure looks something like this:

Figure 1 – Standard Web page layout

 

We’ll create an object and a full spec for the page, based on these main sections.

 

Then we’ll start going down in the hierarchy. The first section (Header) is built out of several objects, and might look something like this:

 

Header Section

We can create a full spec just for the header component, one which we will reuse later on for different pages.

 

Element identification

 

An important part of any Galen visual testing spec is the element identification. For the selection and identification of elements, you can use XPath, id or CSS. Both XPath and CSS are powerful query tools used to uniquely identify any element in the DOM.

 

The main challenge is in providing an identification method that will “hold” (theoretically forever). As a best practice, a good identifier is a short one. For an example “id = header” to identify the main header component.

 

If you find yourself creating complex XPaths which look like:

 

//div[@id=’container1′]/div[1]/div[2]/div[1] – then you will most likely have issues in the maintenance of your scripts and tests.

 

There is a high probability that at some point in time the above identification method will fail or incorrectly identify an element, resulting in a failed test.

 

The preferred option would be to use id as an identification method – as it represents a unique element identifier, usually with a short-straightforward value (e.g the example above “id=header”.

 

What should you do with an element that doesn’t have an id attribute?

 

If you are the application developer it’s easy; You should add IDs to the elements you would like to work with. The problem starts if you are part of the QA team. In our company, The QA and automation team members have access to our web application code and they can add ids for UI elements independently (it took around 2 hours of training for each team).

 

This allows us as a company to create robust identifiers, and therefore – robust test automation for UI components.

 

Gaining some skills in XPath and functions that can be used as part of XPath identification is also a good practice for any team dealing with an UI automation project. XPath is a powerful tool for identification and it can be used to create logical expressions – e.g locate all the elements that have the word “OK”. The XPath can be expressed as:

If we want to identify buttons only, we can add the following logic term e.g –

There are an endless variety of expressions that you can represent using XPath functions like, logical operators and hierarchy searches that you can create using XPath. The content online is wide and you can always find help via sites like W3C or StackOverflow. This is definitely a skill to master when it comes to visual testing automation.

 

Galen Specs – Start with the basic rules

 

The Galen framework introduces a rich page and element layout specification language called Spec. It works by opening a page in a browser, resizing the page and then visual testing the layout using the specs.

 

Here are some basic rules that I would recommend you to begin with:

 

Size – Verify the size of an element.

Inside – Verify that an element is inside another element.

Centered – Verify that an element is centered inside a parent element.

Near – Verify an element is left / right / top / bottom to other element.

Align – Verify all elements are properly aligned.

These rules represent a rule of thumb of 80-20. This means that you can test 80% of your visual layout and structure while utilizing a small subset of the rules and features that Galen has to offer. These are easy to master and highly beneficial when dealing with cross browser testing and responsive web design and development.

 

Galen – Understand groups

 

Groups are an important part of the Galen framework spec. Groups enable you to simplify your visual testing spec files by applying the same rule to several elements at a time. The following is an example of group usage:

In the above example, we have defined a group called “login” composed of 5 different elements (which we have defined in a previous section of the spec file).

Then, we apply two rules in-order to verify that all of the elements in that group are inside another element. We must also identify the alignment of the group elements to the first element in the group.

 

Media Query and CSS Breakpoint

 

Media query and CSS breakpoints are responsive web techniques to create a ‘jump’ in a web page. To see this from a user experience perspective, open the browser on a responsive web page to your maximum screen size, and start to reduce the browser width. You will be able to see ‘linnear’ changes in the page layout, and at certain points when continuing to reduce the page width, you will see a complete layout change. This is the CSS breakpoint.

 

The important part is to understand the browser viewport width ranges that your website is operating.

 

For example, let’s take a website like bbc.com, you will find that it breaks down into the following ranges: 0-599px – very small screens including mobile. 600 – 1007px – tablets 1008 – 1279px – laptops 1280 – max – large screens

 

Breakpoints will affect your rules and introduce a new more advanced topic in Galen which is tags.

 

Importance of specs

 

An important feature of the Galen framework is the capability to import one spec into another spec. With this in mind, I use that to separate object definitions from rules definitions in cases of CSS breakpoint. So if your UI is changing dramatically you will not use tags within the same spec but different specs that define each object once.

Conclusions

 

Galen framework can be a very powerful tool for testing responsive web apps. Implementing visual testing is a must if you implement (or are planning on implementing) full Continuous Deployment.

 

Following these best practices will enable your Galen framework project to be stable and scalable. For more about visual testing check out our tool. 

Guy Arieli – CTO