Galen MD. Automation of the Testing Process

The difficulty of testing the site layout is a common problem. And when we need to test a responsive pattern, the manual testing seems the only solution that comes to mind. However, there is another way to automate the process, namely, to take advantage of the Galen Framework. Read our article for more details!

This framework is based on Selenium and using WebDriver to open the test page in a predefined browser. In case of an error, the framework highlights it in red, takes screenshots and explains why the test has failed.

In fact, the Galen Framework is a markup language. The framework itself and the Galen Specs language, unlike CSS, operates objects on the page instead of using classes. The location of each object is being described and tested in relation to other objects.

Galen is able to...

• check the location of the blocks relative to each other;
• work with Selenium Grid;
• check for visible text;
• run custom javascript on the test page (for example, if you need to open the pull-down menu and check its elements);

• interact with the browser through Selenium, in order to get to the right place on the site, if you can not use a direct link for these purposes;
• perform the component testing. Galen can run separate test files for the specified objects. Thus, it is possible to test repetitive complex elements on a page (for example, search results, comments, etc.);
• make adjustments to the size and position of objects. This possibility can be useful in two cases: either Selenium gives incorrect information about the location of the object, or we need the so-called "guides" (or virtual bind objects) to which we will relate other objects on the page;
• create condition blocks. Such blocks can come in handy if you can not find out which item will be displayed on the page (for example, banners)
• perform parameterization of tests in test suites. Moreover, you can go further and use a parametrization of parametrization (a rare case, of course, but it can also be useful. For instance, you can run the same test for different sizes and even for different browsers).

In order to demonstrate the work of this framework, we've chosen our project http://mobile.design/. Using the example of site header, we'd like to show the process of writing and execution of basic tests.

Here goes!

Of course, the whole process starts with installation.

sudo npm install -g galenframework-cli

(to run the test in Chrome browser, make sure that the Chromedriver is installed)

Next, we need to configure Galen http://galenframework.com/docs/getting-started-configuration/

Visually, the header of this site (mobile.design) has the following elements:

The purpose of writing tests in Galen is a visual representation of how the site should look like in the browser. In other words, the test itself should be as clear to the developer as possible and help us to understand what we will see.

Using the above image, you can understand how the markup will be built in HTML and how the "locators" for the test items will be specified.

In Galen, you have three types of locators: id, CSS, XPath. We advise you to avoid XPath or use it only in rare cases when id and CSS items do not allow to select the desired element from the page.

Now it's time to create a file “homepage.gspec” and describe our objects.

@objects

 header            header

   navbar          header .navbar

   logo            header .navbar .navbar-header .logo





 menu-tabs         #category-menu ul

   item-*            li



 main-menu         #main-menu  .navbar-nav

Names of some objects include the item "*": this is necessary if there are a lot of similar elements on the page. In this case, Galen should find all the elements on the specified "locator" at first, and then it creates objects with the referenced name (though, instead of the * symbol, Galen uses the serial number, starting with 1).

Let's take menu-tabs-item- * as an example. The mobile.design site has 5 such category tabs, and they will be processed sequentially and given the appropriate names: menu-tabs-item-1, menu-tabs-item-2, etc.

Next, we should explain to Galen, on what principle the objects will be tested. Since we are primarily interested in the responsive theme, the most obvious tags for testing will be the following ones: all, desktop, mobile.

We also invite you to pay attention to the Galen Test Suites. This will help you avoid running various commands separately and reading reports in different folders. So, we're going to create the md-galen.test file and write the following lines

@@ Parameterized

  | device   | size       | tags        |

  | desktop  | 1024x768   | all,desktop |

  | mobile   | 400x600    | all,mobile  |

Mobile.design Home page in ${device} device

   http://0.0.0.0:8080  ${size}

       check homepage.gspec --include "${tags}"

(all manipulations with Galen is taking place on the local version of the site but you can specify any URL)

Now, following the documentation, we begin to describe the objects according to the used tags.

For example, the header object has a height property of ~ 90px, and in this case, it will be the same for the mobile and the desktop versions. However, let's consider another example. In the main-menu object, both versions have cardinal differences: in mobile variation, the menu turns into a "hamburger" with a pull-down sub-menu. Accordingly, the menu that is typical for the desktop version will be absent in the mobile one.

= Header section=

 header:

   height ~90px

   inside screen 0px left right



 header.logo:

      on top left edge header.navbar -1 px left, 4 px top



 main-menu:

   @on desktop

     inside header.navbar ~0px right, 1px top

   @on mobile

     absent



= Categories menu =

 menu-tabs:

   @on desktop

      below header 1px

      centered horizontally inside screen

   @on mobile

      absent



 menu-tabs.item-*:

   @on desktop

     width >= 50px

     height ~ 71px

   @on mobile

     absent

Running tests is done by command

galen test md-galen.test --htmlreport reports

where "reports" is the folder created for storing the reports. The file “reports.html” which contains links to both versions being tested will show the number of errors.

How else can you improve the code? If you look through the documentation carefully, you can find Custom Rules. In short, it's something similar to a function, only parameters are being parsed from a normal sentence written by the user. This will greatly optimize your test code.

As a conclusion, we’d like to say that Galen is a powerful tool for visual layout testing which, with the right approach and clearly formulated requirement specification, can save your time, efforts and nerves.

So we should say “Good luck!” and wish that you see only the green lines in your test reports!