To anyone interested in accelerating their Test Automation work, here's an article that could well help to point the way ahead! It also covers the production of multi-lingual validation data.

1. PAGES TO GO
Generating Page Objects
D. Harrison
April 2023
© 2023, David Harrison, All Rights Reserve

2. Table of
CONTENTS
Introduction.............................................................................1
The Context.............................................................................1
The Page Object Structure.........................................................3
Textual Validation.....................................................................8
Translation Service ...................................................................8
Page Actions.......................................................................... 10
Generation: Overview ............................................................. 12
Generation: The Meta-Data ..................................................... 13
Generation: The Translation Data Source .................................. 15
Generation: The Object Model.................................................. 16
Generation: The Template ....................................................... 17
Generation: The PoC Codebase ................................................ 19
Generation: The Output .......................................................... 24
The Jett Application ................................................................ 28
Remarks ............................................................................... 33

3. INTRODUCTION
One, if not the, most important themes in a Test Automation approach is of that
of using Page Objects to represent visible pages or parts of the pages of a
target application.
The Page Object design pattern for Test Automation was first suggested by
Martin Fowler back in 2013 (here).
Whilst this pattern has been widely adopted by test practitioners, at least
judging from the content on the web, creating Page Objects for rich UI pages is
a task that needs care and attention. In addition to the general work of creating
Page Object classes, we need to consider the validation services they need to
provide to the test layer. Such validation needs to be performed, in modern
web applications, across a range of spoken languages, e.g. English (EN), French
(FR), German (DE) etc. We have seen the Page Object pattern in previous
Articles, such as (here), (here) and (here).
In this article, we will look at how Page Objects can be created from meta-data,
specifically data specified in an Excel Workbook. As in the previous work, the
driver here is twofold: (1) to produce working Page Object classes fast, and (2)
to embrace application change fluently. We will also introduce an early-stage
application that embodies the presented approach, a desktop application, Jett.
THE CONTEXT
The target application under test we will use is the GridGain Nebula control
application we looked at in detail previously from a Test Automation perspective
(here). This application offers only English as a language for displaying textual
elements, but for the purpose of this article, we will assume that it offers,
additionally, German and French.
In contrast to the earlier article, we will only consider the initial landing page of
the application, as shown below, which in the terms of our overall Test
Automation approach, comprises three components - the title strip at the top of
the page, the sign-in panel itself and the reset password panel (which shows
when the “reset password” link is clicked), see also below.

4. 2
Landing Page + (Title Strip + Sign-In Panel) Components
Landing Page + (Title Strip + Reset Password Page) Component
The main aim of breaking pages down into Components is to separate out the
complexity of an application and thus make it more manageable as well as
maintainable.

5. 3
THE PAGE OBJECT STRUCTURE
The Page Object is seen here as a provider of services to the tests being
executed.
In addition, all the basic application method calls, e.g. Selenide, as well as their
associated locational data, are only found in the individual Page Objects. This
satisfies our wish to have a Separation of Concerns pattern in the code as well
as going a long way to improve readability and maintainability of the overall
framework.
The general structure of our framework, then, is as shown below:
Each Page Object class follows an identical pattern. This organisation was
developed as part of the work described in the earlier work (here) in the
context of XML meta-data generating Java/Selenium code. In this current work,
we will see how this generational process can be revised to embrace an Excel
meta-data source from which is generated Java/Selenide code.
A fragment of a Page Object is as shown in the following figures:
BDD
Stmnts
Step
Defns
Page
Objects
App.
Cucumber Java Java/Selenide

6. 4

7. 5

8. 6
The application corresponding to the above, is the GridGain management
application which was looked at in detail, from a Test Automation perspective,
in an earlier article (here).
The above Page Object class reflects the landing page of the application, when
the user browses to the primary URL of the application, wherein lies a LogIn
panel. This panel also has a password recovery link.
The following table highlights some of the feature’s observable in the above
figures:
Location Comments
Line 30-31 Specifying the constants that are used when retrieving the language-
dependent text from the translation service
Line 37-39 Declare the class signature of the Page Object. Note the base class
dependency. This base class is instantiated using the test context object, of
type TestContextJava. The current spoken language mnemonic, e.g. “EN”,
“DE” etc, is also a constructor parameter. Note: there is a specific naming
convention for Page Object classes <application-name>_<page-
name|component-name>

9. 7
Line 41 The name of the page represented by the Page Object is specified,
“LandingPage”
Line 45 The translation service object is instantiated using the current language
mnemonic and test context object
Line 49 Here we set the primary URL of the application. For Page Object classes that
are displayed as part of the application workflow then this value is the
empty string
Line 51-59 These statements are where the components “owned” by the page are
specified. In the current case, we have three components: the title strip at
the top of the landing page, the sign-in panel and the reset password panel
(Note again the naming convention for Page Objects)
Line 61-66 Here we set up the test context object (name/object collection) which holds
named objects we want to use elsewhere in an executing test
Line 72 Here we have a utility method that uses an existing method to wait for the
page to be fully rendered when executing a test. Note: Under some
circumstances, the way we detect full-page rendering completion might
require special attention
Line 78 Here we have another utility method that uses a Selenide method to browse
to the specified page URL, in the case when one has been specified. Note:
Under some circumstances, the way we browse to the target location might
require special attention
Line 83-95 In this section, we set the locator string values for the visual elements
which can be validated on the page, e.g. companyHeaderLocatorString, as
well as companion unique constants used when signalling what validations
are to be performed, e.g. validateCompanyHeader. Note: the naming
convention used here
Line 97-105 Here we define methods used when specifying the validations we want to
have performed within a test, e.g. validateCompanyHeader(). These methods
can be used fluently in that they return the instantiated Page Object itself.
Within the method we OR together the specific validation constant with an
overall validation bitmask. This latter value is what is used in the primary
validation method (see next table entry) to scope what elements are to be
tested. Note the naming convention used here
Line 107 on At this point, we see the primary validation method being defined. Since we
are generating its content we see a sequence of similarly patterned code
blocks (a fragment of one is shown). This block structure is one that can be
expected to be easily optimised by a modern compiler.
We will look at further aspects of the code structure in the following sections.

10. 8
Textual Validation
In the primary page validation method, validatePage(), the individual element
validations appear as blocks, such as exemplified in the figure below:
If the overall bitmask, validationSet, has the specific bit set corresponding to
the required validation item, then following an entry being written to a logging
file (Line 129), we retrieve the expected value from the Translation Service
(Line 130-131, see next section).
Provided the Translation Service returns an expected result at all with the
provided key (see Line 30-31), then we proceed to compare this with the text
retrieved via a Selenide call (Line 137-138). The reason for the non-optimum
approach of storing the actual value in a temporary variable is to allow for
debugging. Sometimes the retrieval step might indicate issues with the locator
being used and the value gathered would indicate this during debugging of the
overall test code.
If the expected and actual texts do not match, in the case shown above, by full
comparison, then an error signalling bitmask is set along with a name entry in
an error list. These will then be reported at the top-level test level. Other
comparison formats are possible.
Translation Service
The Translation Service is the basis of our framework approach to testing
internationalised (i18n) applications.

11. 9
The data used is held in a JSON file within the IntellJ development/execution
framework. The initial fragment of this file, appropriate to the GridGain Nebula
application, is shown below:

12. 10
Our target application has only the English language as an option, but for the
purpose of illustration our data source contains words and phrases for German
(“DE”) and French (“FR”) (Thanks Google Translate 😊 ).
As noted in the earlier section, all Page Object classes define translation keys
for all the elements that can be validated in a test, so, for example, to retrieve
the label shown on the login page that invites the user to login, we see a key
value of “sign-in-panel-comp.label.label”. This key is further appended with
the current language mnemonic setting to provide the final JSON look-up path
to the corresponding expected text.
Normally, this file would be maintained by hand. However, as can be
appreciated, this process is error prone and laborious, so its production is
embraced by the generation process described here.
Page Actions
In our Page Objects we also need methods that allow actions to be performed
within the scope of a page. The definition of these actions is covered in the
Excel meta-data.
Some examples of action methods are given below:
As in previous sections, it is to be noted how we use a specific naming
convention for these methods which lends itself, as elsewhere, to a generation
process.

13. 11
In each of the examples shown above, Selenide method calls are used, both in
the assertion of visibility and enablement as well as in the actual statement
which performs the required action (in this case a “click” on/of something).
There are also actions that require a parameter, examples of which are given
below:
Here we see the pair of methods that enter text, with or without a termination
character, in the Email and Password text boxes respectively. If we were writing
this code by hand we would probably have one method to enter text in a
generic text box, but in the generation space we don’t proceed along those
lines. Since the code is generated we don’t worry about traditional
“maintenance” and being frugal with the lines of code count. The modern
optimising compiler will make short work of such simpler coding structures!

14. 12
Generation: Overview
We use a programmatic template approach to the generation of Page Objects.
In the first instance the data source of this template approach is meta-data held
in a spreadsheet (XLSX).
The figure below shows the initial setup for our generation approach:
The meta-data is read from XLSX Workbook by a Visual Studio unit test, at this
point, and used to construct an object model of the defined pages.
This object model is then used to populate, for each defined page, a T4 text
template, which is then transformed into its textual form. The textual
representation is the written to an output location as a C# class file, the target
Page Object. In addition, as described in detail below, the expected value data,
for the range of spoken languages offered by the application, is written to an
appropriate JSON data file.
XLSX
Meta-data
Visual
Studio
Page
Object
XLSX
C#/.Net
T4 Templates
Java/Selenide
JSON
Value
Data

15. 13
Generation: The Meta-Data
The XLSX workbook is split into a number of worksheets:
• The general configuration data
• A sequence of sheets specifying data for the individual “pages” in the
application to be tested.
The configuration worksheet looks as shown below:
The data specified has the following meaning:
• ApplicationName – the name assigned to the target application. This will
be used throughout the generated code so it needs to match the needs of
a programming language.
• Languages – this specifies the range of spoken languages handled by the
application by their mnemonic (comma separated list).
• DefaultLanguage – specifies the default, startup, language for the target
application, by its mnemonic.
For this article we will be looking at the GridGain Nebula control centre web
application, which you can find (here). This application only offers “EN”/English
as a language, but for the purpose of illustration we will assume that it
additionally offers “DE”/German and “FR”/French.
The two additional worksheets are those associated with the landing page of the
application, where you arrive when you browse to the primary URL, and the
SignIn panel component, which conceptually, within the context of our test
automation framework, is contained or owned by the landing page.
The worksheet for the LandingPage is as shown below:

16. 14
The data specified has the following meaning:
CodeComment – this represents the descriptive comment that will appear at
the class-level in the generated code.
URL – this is the target URL of the page and since this is the initial landing page
we specify the base URL. When a page is arrived at via application workflow,
this item is the empty string.
Components – this is a section holding data about all the components
contained within the page.
o Name – this is the name to be assigned to the page. This name is
used in the generated class so needs to be compiler friendly.
o LocatorString – this is the base CSS locator string of the component.
This locator will be used to generate methods that check the existence
of the component.
TextValidations – this section itemises the textual items that are to be offered
by the Page Object as being possible to validate on the page in a test.
o Name – this is the name to be assigned to the page. This name is
used in the generated class so needs to be compiler friendly.
o LocatorString – this is the CSS locator string of the item to be
validated.
o Value – this is the expected value of the item to be validated.
o Form – this specifies the way in which we will compare actual and
expected values:
▪ Full – the full extent of the values will be compared.
▪ StartsWith – the actual value starts with the expected value.
▪ EndsWith – the actual value ends with the expected value.
▪ Contains – the actual value contains the expected value.

17. 15
o TransKey – as noted above, within our testing framework there is a
Translation Service which allows us to retrieve the expected value of
items in any of the required spoken languages. In the example being
looked at here we can retrieve values in “EN”, “FR” or “DE. The values
provided must be a valid JSON key and it has the form:
page-name.value-style.value-name
The next section shows the structure of the JSON data source.
Actions – this section defines the range of actions that the Page Object will
offer to tests.
o Name – this is the name of the action and will be used in the generated
class so, as above, needs to be compiler friendly.
o LocatorString – This specifies the CSS selector of the element upon
which the action will be performed.
o ActionType – This defines the type of the action performed, either
Exist, Click, Clear, Get, Enabled, Enter. This action type word will be
used in the generated class so needs to be compiler friendly. Example
signatures of such methods would be:
public void doSaveClick()
public String doNameTextBoxGet()
public void doNameTextBoxEnter( String value )
Generation: The Translation Data Source
The source of data for the framework Translation Service is a JSON data file
located in the project structure. This file links JSON style keys appended with
the current target application spoken language mnemonic, to expected textual
values. This data is used in the validation services referenced by the Page
Object.
This data for our GridGain Nebula application takes the form as shown in the
initial file fragment below:

18. 16
Generation: The Object Model
The definitional meta-data is primarily used to construct a corresponding object
model representing the pages and the validation and action services to be
provided by them to tests.
This object model is used to seed the text template, via properties, the
necessary information.

19. 17
Generation: The Template
Along with the object model another central component of our generation
approach is an appropriate T4 Template (this technology is available within
the .Net environment (here)).
A fragment of our Page Object template, ApplicationPage.tt, is shown below:

20. 18
From this it can be seen how the objects from the model feed into the
generation template. For example:
Line 32: Page.PageCodeComment
Line 38: Configuration.ApplicationName & Page.PageName

21. 19
We also see how embedded control statements also drive what is produced, for
example:
Line 41-49: namePrefix & transKey
Whilst, these latter aspects are clear from the above fragment view, how do the
object model components enter the picture?
At the end of the text template file we find a feature control block which allows
the instantiated template to have data passed to it at run-time, e.g.:
Generation: The PoC Codebase
To ensure we have a viable approach, a small PoC unit test is used to run our
generation process (and generate only the Page Object classes). The code looks
as below:

22. 20
This code does the following:
1. Line 59: Read the XLSX meta-data (the page object model as we have
seen in the earlier section where the object model was introduced, has an
additional, parameterised constructor, which allows the full path to the
XLSX file to be specified).
2. Line 61: Retrieve the Configuration object from the model.
3. Line 64-79: Loop over the Page objects defined in the model.
4. Line 66-70: Instantiate the text template class using an object initialiser
pattern. This sets the properties of the text template we saw in the
previous section, in the template feature control block.
5. Line 72: Using the instantiated text template instance, we invoke the
text transformation method – the target Page Object class is generated as
a string.
6. Line 74-78: Constructing the target file name from both Configuration
and Page object data, we write the generated data to a target location.
As we noted in the section where we looked at the JSON-based i18n data
needed by the automation framework Translation Service, we should also
generate this as part of the overall process.
As with the page generation process, we first ensure that our planned process
produces a correct outcome via unit test, which is as shown following:

23. 21
This code does the following:
1. Line 151: Read the XLSX meta-data.
2. Line 154–198: We loop over the pages defined in the Object Model.
3. Line 159-163: We loop over the TextValidations in the page and build a
list of items reflecting the data that reflects a single JSON item.
4. Line 166: – The JSON string starts life as an object of type
StringBuilder, and this is initialised with the opening “{“ here.
5. Line 167-174: The list of items we built in the loop beginning at line 154
needs to be ordered into groups so that we end up with optimum, valid,
JSON. Here we use the LINQ extensions of the List<T> type to perform
this transformation.

24. 22
6. Line 177-196: Here we use the organised data to build the eventual
StringBuilder object.
7. Line 196: Here we append the terminating “}” character to the JSON
representation. In addition. If we are not processing the last page
definition, we append a “rn”.
At the end of this unit test (Line 204) we expect to see the sb.ToString()
method returning the expected optimal, valid, JSON data. If we copy/paste this
from the Visual Studio Local variables panel into an appropriate text editor,
then we see as follows:

25. 23
Here can be see the result of the LINQ-based grouping step mentioned above –
all the same-type items are grouped together within a page structure.
As a final confirmation step, if we take this textual output and paste it into an
online validator (e.g. here) we see that it validates successfully:

26. 24
Generation: The Output
We have now confirmed our general approach as being correct, so let’s check
the thing we really want from this generation process, the Page Object classes.
Nebula_LandingPage
The following fragment shows the first few lines on the Page Object class,
Nebula_LandingPage:

27. 25
The notable parts of the class are:
1. Line 24: The signature of the class extending the general page base
class.
2. Line 27-28: The appropriate JSON format keys needed to retrieve the
appropriate values of textual items that can be validated, are specified.
3. Line 33: The signature of the main constructor which shows how the Test
Context object and the current spoken language mnemonic enter the
scope of the class.
4. Line 35: The base class is instantiated using the Test Context
5. Line 37-46: several data items are initialised. Key to note here is the
instantiation of the Text Translation service at Line 41.
6. Line 49-57: The set of components defined in our meta-data as being
“owned” by the Page Object are instantiated.
7. Line 62-64: Insert some basic data into the Test Context data store,
referencing them by key.
If we now look at the generated action methods that the Page Object offers the
tester, we see:
These methods involve a particular naming convention, as vital in a code
generation process. The names are in the form:
do[action-name][action-type]
Where the parts in brackets ([]) are specified in the meta-data.
Line 187: A method to check the existence of the TitleStripComponent
Line 193: A method to check the existence of the SignInPanelComponent
Line 198: A method to check the existence of the ResetPasswordPanelComponent

28. 26
Each of these methods start with logging a message to the Validation Logging
service and then, using Selenide methods, appropriately validating the
existence of the corresponding element. Whether the logging actually happens
is controlled by a runtime environment variable, which would also be used at
the command-line of a CI/CD test execution tool.
Nebula_SignInPanelComponent
Shown below is a fragment of the Nebula_SignInPanelComponent class:

29. 27
The general pattern, as can be expected, is as we saw for the
Nebula_LandingPage in the previous section.
Looking at the generated action methods, we see:
In the previous section we saw action methods that check for the existence of
an element, and these types of methods repeat here. However, as defined in
the meta-data, we now generate methods for entering data, Line 499-508.

30. 28
The Jett Application
We now have a confirmed approach for our generation infrastructure. Of course,
the foregoing sections were based on an Excel data store being read by unit
test code, the simple task of which was to provide confirmation of the approach.
Now, however, we would like to transform this startup structure to one
embedded in a more generic tool – enter the Jett application.
What we present in this section should be thought of as a PoC of an eventual
fully rounded application, perhaps even a web application.
Jett is a Windows Forms desktop application which at startup looks as shown
below:
The main part of the application, below the menu bar, is a TabStrip control, the
first three pages of which represent the data we saw in the Excel data in the
previous sections. The first TabPage, “Configuration”, is on display and shows
as a contained DataGridView control populated with the meta-data we saw in
Excel. Only the data in the “Value” column is editable.
The next two pages show the meta-data for the application pages
“Nebula_LandingPage” and “Nebula_SignInPanelComponent” respectively. As in
the “Configuration” case, these two pages host a DataGridView control, and
show as follows:

31. 29
In these pages the non-grey cells are editable and additional rows can be
added.
As noted earlier, as part of our generational approach, we embrace the
production of the JSON Translation Service data for all the pages in the meta-
data. This is shown below:

32. 30
This data is displayed in a TabPage-hosted SyntaxEditor1 with the
JsonSyntaxLanguage language binding. This page content is set ReadOnly, but
the generated file is editable.
Finally, we see the key output of our generator, the Page Object classes,
“Nebula_LandingPage” and “Nebula_SignInPanelComponent”.
1
https://www.actiprosoftware.com/

33. 31

34. 32
These Java classes are displayed in a SyntaxEditor with the JavaSyntaxLanguage
language binding. Whilst in Jett these pages are set to be ReadOnly, the files
themselves are editable.

35. 33
Remarks
In this Article we have shown an approach to accelerate the production of Page
Objects through generation.
This approach has a two-fold objective:
1. To accelerate the production of rich Page Object classes
2. To embrace change in the structure of application pages efficiently
Both these objectives are met.
The Jet application is currently at the PoC stage; however, it is intended to
finalise the design over the next months.
Investigating an online version is also in-scope.