Saturday, 4 March 2017

This week I was trying to find/learn a way to create pattern
of code in some of the automation I’m working with. The pattern would allow the
listing out of collections of items, say links or page tabs, then iterate over
each one testing they are working as expected.

Page Object / Page
Flow

There are some simple ways of doing this, but the challenge
was to follow coding standards used in the project. One aspect of which is to
follow the Page Object / Page Flow model. Essentially that means having
automation tests that are separated from the code that describes the page
elements and how we interact with them. So how to create a test that can call
page-stuff in a generic way.

Enumeration

Enums in C# allow us to make unordered lists of items (I
learned there is an ordered list too), like links or tabs, then use them in
other things like Dictionary lists. Where we could then have values
(definitions) assigned to the list items. That seemed like a good way to
declare an item of interest to check in the test and give it the ID as a string
from the HTML on the page.

Here’s what the main pieces of the header section I wanted
to find looked like in an enumerated list.

publicenumenumElements

{

Logo,

ApplicationName,

Welcome,

OrgSelector

}

Dictionary

To assign each of these items of interest a string value
that matches the ID in the HTML I used a Dictionary list, knowing I could pull
out the value element (the string) later for use in the actual test. Here’s how
the Dictionary pulled in the item and assigned the value.

publicstaticIDictionary<enumElements, string> ItemName

= newDictionary<enumElements, string>

{

{ enumElements.Logo, "logo" },

{ enumElements.ApplicationName, "application-name" },

{ enumElements.Welcome, "welcome" },

{ enumElements.OrgSelector, "org-selector" }

};

The Unit Test

The objective here was to see if I could build a Unit Test
that did NOT contain the actual values being tested. The idea there of course being
that if the page changed, the test would still stand; just the underlying
values would need changing. (Idea: can we make the dictionary items more
generic?)

Here’s the Test Method from the unit test:

[TestMethod]

publicvoid TestMethod1()

{

foreach (var item in ItemName.Values)

{

Console.WriteLine($"We have: {item}");

}

}

The theory here being – if we can do a WriteLine on each
item Value, then we could replace Console.Writeline with meaningful Selenium
test code. That could be asserting the presence of each item in the page for
example or clicking on it. Running the test worked and the output was a list of
the string Values.

Phew! That only took 2 days, but now we have a pattern for
building a list of pretty much anything and testing them in an iterative
fashion. Literally, if we have a set of links, tabs, items in a drop-down; the
above will make it easy to test them.