End To End Testing — Using JSON files to drive simple layout testing
Scenario: you have a product with the following characteristics:
- 9 month release cycle
- 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:
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.