Element repository

Most of test automation scenarios revolve around view elements and their state. The view elements are small parts of app's interface, examples of view elements are a button, a list item, a video progress bar, a container.

The state of a view element changes when an application receives input from the user. For example, a common button can have a gray background and a focused button can have a blue background.

Any test automation scenario is essentially a sequence consisting of:

  • User input commands
  • Assertions about a state of a particular element.

Push a few buttons or make a few clicks and then compare the current state of the element with a baseline snapshot of that state.

Element repository (Elements tab) contains all your view elements along with the baseline snapshot of their state. It is your central view element storage, that is accessible from the Test editor (Tests tab). If you are familiar with modern test automation concepts, you can think of the elements within the repository as page objects with advanced functionality.

Embracing Reuse

During test automation, it is very important to avoid duplication in tests for the reduction of future maintenance and to save time. The Element repository was designed with this in mind and has several features to help to achieve maximum reuse and therefore increase the efficiency of testing.

Snapshot data can be referenced from test

Consider the following situation:

You have created 100 tests most of them relying in some way on an item focus color being blue. But then the application design changes and the item focus color is now red, so the tests start failing. It would be a hassle if you had to rework all of your tests just because of this change.

To help avoiding a scenario like this Suitest provides a way of specifying an assertion value dynamically. Instead of literally specifying color = blue, you can state color = whatever is currently in the repository. This way the color value is stored in a single place - the element repository and when a redesign occurs only that single place will need to be updated for your tests to function again.

We call the literary specification color = blue to be a user value. The specification color = whatever is currently in the repository we call a default value.

Every element assertion is created with default values pre-filled. Where necessary the default values can be overwritten with user values and user values can be reset back to the default values. The picture below demonstrates both value types

Example element assertion. The fields highlighted in orange are the user values. The gray fields are the default values (stored in the repository)

Element snapshot can be defined for each platform

When developing a multi-platform application, try to make tests that are platform independent (work on any platform) to benefit from reuse that Suitest offers.

Consider the following test scenario:

On the home page select the first item in the list of videos and make sure the video plays back correctly.

This scenario is clearly suitable for any platform. The catch is that the "first item" and "video" may refer to different elements on different platforms.

Suitest allows defining an element representation (identifying properties and a baseline snapshot) for every platform separately enabling you to write cross-platform test automation scenarios.

Porting your test scenarios to a new platform can be as easy as going through your saved elements and updating their baseline snapshot for this new platform. The test scenarios will then become compatible with that new platform.