End To End Testing — Using JSON files to drive simple layout testing

Photo by ThisisEngineering RAEng on Unsplash

Scenario: you have a product with the following characteristics:

• 9 month release cycle
• multilanguage
• lot of features that have a common UX usability pattern
• in each new version you add features: new filters, new function buttons, new column on output grid

You need to be sure you have not introduced regressions like:

• some filter present in version N-1, has disappeared in version N.
• labels for filters, buttons and columns have changed.
• you are not using the standard label translation.
• default value for filter has changed.
• mandatory fields are not mandatory anymore.
• date from / date to range has changed.

To solve this challenge the first thing to do is create a helper class that provides following methods:

validateFiltersLabelsAndDisplayOrder()

validateMandatoryFilters()

validateReadOnlyTextFilters()

validateReadOnlyDateFilters()

validateReadWriteTextFilters()

validateReadWriteDateFilters()

validateDomainForComboFilters()

validateDomainForTextFilters()

validateFiltersDefaultValue()

Nothing new, ok?

Then you can create some sort of template test script for this kind of layout validation.

The question is: what is the more efficient approach to pass all the data needed for the validations.

Because we are using Page Object Model (POM) to manage the different pages of our application, it can be seams that POM is the right place.

But if we think that we want to allow not developers to help with construction of these kind of test, POM is not the right solution.

An approach I’m using with good results is the following:

• script name testcase-123-users-layout
• layout configuration for Italian: testcase-123-users-layout.ita.json
• layout configuration for English: testcase-123-users-layout.eng.json

this naming convention (convention over configuration) simplifies configuration loading.

Then in the json file I’ve created an object with these properties

filters: array with the filters labels

buttons: array with the buttons labels

columns: array with the grid columns labels

mandatoryFilters: array with the labels of the mandatories fields

howToGetItems: object: provide labels and values in order to do a search to get items

defaults: object: for filters that have a not empty value as default

filtersEmptyByDefault: array of labels

comboFilters: array of labels, we will use this to validate each combo has NOT empty domain

RWTextFilters: array of labels

RWDateFilters: array of labels

I’ve developed a simple method to map Labels to POM properties.

We organize the test script repository with a branch for each Application Version to be released.

The update of the validations. i.e. one more filter, a filter removed can be done in a simple way for the same business analyst that have changed the feature UX specification, changing the JSON in the right branch.

These JSON files can be also generated by the developers with some simple script.

I’ve found this approach effective, and allows you to add this kind of test for a new feature with low effort.

Hope this kind of approach be useful for you.