Design Patterns for QA Automation

1CONFIDENTIAL
Design Patterns for QA
Automation
Anton Semenchenko

2CONFIDENTIAL
1. Main challenges
2. Solution
3. Design Patterns – the simplest definition
4. Design Patterns language – the simplest definition
5. Encapsulation – the most important OOP principle
Agenda, part 1 (general)

3CONFIDENTIAL
1. Page Element
2. Page Object
3. Action
Agenda, part 2 (main patterns)

4CONFIDENTIAL
1. Flow (Fluent Interface)
– Ubiquitous language
– Key word driven
– Behavior Driven Development (BDD)
2. Domain Specific Language (DSL)
– Flow
3. Navigator (for Web)
Agenda, part 3 (less popular patterns)

5CONFIDENTIAL
1. “Rules” and principles
2. A huge set of useful links
3. A huge set of examples
Agenda, part 4 (take away points)

6CONFIDENTIAL
1. Pure design
2. Over design
2 main challenges in our every day work (interview experience)

7CONFIDENTIAL
1. Find a balance
Solution

8CONFIDENTIAL
1. Elements (blocks) of reusable object-oriented software;
2. The re-usable form of a solution to a design problem;
Design Patterns – the simplest definition

9CONFIDENTIAL
1. Design patterns that relate to a particular field (for example QA Automation) is called
a pattern language
2. Design Patterns language gives a common terminology for discussing the situations
specialists are faced with:
– “The elements of this language are entities called patterns”;
– “Each pattern describes a problem that occurs over and over again in our (QA Automation)
environment”;
– “Each pattern describes the core of the solution to that problem, in such a way that you can
use this solution a million times over, without ever doing it the same way twice!”
Design Patterns – as a language

10CONFIDENTIAL
1. Design patterns that relate to a QA Automation field:
– Page Element
– Page Object
– Action
– Flow
– DSL
– Navigator (for Web)
Design Patterns for QA Automation

11CONFIDENTIAL
1. Ask yourself "how can I hide some details from the rest of the software?“
2. As with any encapsulation this yields two benefits (QA Automation, Page Object Design
Pattern context):
– store logic that manipulates the UI to a single place you can modify it there without affecting
other components in the system;
– it makes the client (test) code easier to understand because the logic there is about the
intention of the test and not cluttered by UI details.
Encapsulation – the most important OOP principle

12CONFIDENTIAL
1. Page Element – encapsulates “complexity” of UI element, canonical example – table as a
part of UI.
2. Page Element – the simplest Page Object (Page Object with one and only one UI element)
3. Let’s focus on Page Objects and then return back to Page Element Design Pattern.
Page Element

13CONFIDENTIAL
1. Page Objects – encapsulates the way of identification and logical grouping of widgets.
2. Page Object == Logical Page
3. Page Object != Physical Page
Page Object

14CONFIDENTIAL
Page Object – classical example (state-less approach)

15CONFIDENTIAL
Page Object – classical example (state-less approach) 

16CONFIDENTIAL
1. Aggregation
2. Inheritance
– Much more complicated then aggregation.
3. Summary:
– prefer aggregation to inheritance in mooooost cases;
– before start implementation based on inheritance, please, take a break for a minute, and re-
thing everything again, possibly you can find a proper solution based on aggregation.
2 ways (main, in 99% of cases) of re-usage any entity in OOP

17CONFIDENTIAL
1. Let’s compare:
– Photo
• Share – looks like parallelism (easy parallelism).
– Video
• Share – looks like parallelism (not trivial parallelism).
State-less or state-full solution?

18CONFIDENTIAL
1. How easy transform solution from “single” to “multi” threading (to decrease “QA
Automation Windows”)
– State-less – like share a photo
• Just 5 minutes of work.
– State-full – like share a video
• Not trivial task, could be a night mare.
2. Summary
– prefer state-less solutions to state-full solutions in mooooost cases;
– before start implementation a state-full solution, please, take a break for a minute, and re-
thing everything again, possibly you can find a proper state-less solution.
State-less or state-full solution?

19CONFIDENTIAL
1. Static class
– could be implemented as a state-less solution easily
2. Object
– State-full solution in 99,99% cases
3. Summary
– prefer static class based solutions (state-less) to object based (state-full) in mooooost cases;
– before start implementation based on objects, please, take a break for a minute, and re-thing
everything again, possibly you can find a proper solution based on static classes.
Object or static class State-less or state-full solution?

20CONFIDENTIAL
1. Static classes based
2. State-less
3. Summary:
– Such an implementation (the simplest one, state-less) – is a proper one in most cases;
– You can find dozens of examples in this presentation.
Page Object – the simplest implementation

21CONFIDENTIAL
1. UI Map – one entry point
– One entry point, tree of Page Objects;
– One entry point, tree of locators.
UI Map

22CONFIDENTIAL
1. Web UI that behaves like a Wizard
2. Web UI in combination with Mobile in one use case
3. Internet of Things (in most cases)
4. More then 1 page during 1 test (for example several portals or several instances of one
portal to implement one “business use case”):
– Really seldom;
– Looks like integration tests (in most cases):
• Std solution- some type of White Box Testing.
5. Many others “special cases”
Page Objects – state-full, special cases

23CONFIDENTIAL
Page Object – special case example (state-full approach)

24CONFIDENTIAL
1. “Page objects are a classic example of encapsulation - they hide the details of the UI
structure and widgetry from other components (the tests).”
– “store logic that manipulates the UI to a single place you can modify it there without affecting
other layers in the QA Automation solution (architecture)”;
– “it makes the test code easier to understand because the logic there is about the intention of
the test (focus on business logic) and not cluttered by UI details”.
Page Object by Martin Fowler

25CONFIDENTIAL
1. “When you write tests against a web page, you need to refer to elements within that web
page in order to click links and determine what's displayed.”
2. “However, if you write tests that manipulate the HTML elements directly your tests will be
brittle to changes in the UI.”
3. “A page object wraps an HTML page, or fragment, with an application-specific API, allowing
you to manipulate page elements without digging around in the HTML.”
4. ”Page Object should allow a software client to do anything and see anything that a human
can.”
5. ”Page Object should also provide an interface that's easy to program to and hides the
underlying widgetry in the window.”
Page Object by Martin Fowler, “general” rules

26CONFIDENTIAL
Page Object by Martin Fowler

27CONFIDENTIAL
1. “The page object should encapsulate the mechanics required to find and manipulate the
data in the UI control itself”
2. “Changing the concrete control - the page object interface shouldn't change.”
3. “A page object wraps an HTML page, or fragment, with an application-specific API,
encapsulate a way of page elements manipulation (without digging around in the HTML).”
4. ”A page object should also provide an interface that's easy to program to and hides the
underlying widgetry in the window.”
Page Object by Martin Fowler, “encapsulation” rule

28CONFIDENTIAL
1. “A page object wraps an HTML page, or fragment, with an application-specific API,
allowing you to manipulate page elements without digging around in the HTML.”
2. “Despite the term "page" object, these objects shouldn't usually be built for each page, but
rather for the significant elements on a page”
3. “A header page object and a footer page object – canonical examples.”
Page Object by Martin Fowler, “logical page” rule

29CONFIDENTIAL
1. “Model the structure in the page that makes sense to the user of the application.”
2. ”Page Object should allow a software client to do anything and see anything that a human
can.”
3. “Some of the hierarchy of a complex UI is only there in order to structure the UI - such
composite structures shouldn't be “showed” by the page objects.”
Page Object by Martin Fowler, “hierarchy of a complex UI” rule

30CONFIDENTIAL
1. “To access a text field you should have accessor methods that take and return a string,
check boxes should use booleans, and buttons should be represented by action oriented
method names.”
2. “Page object operations should return fundamental types (strings, dates) or other page
objects.”
3. “If you navigate to another page, the initial page object should return another page object
for the new page.”
Page Object by Martin Fowler, “should return” rule

31CONFIDENTIAL
1. “There are differences of opinion on whether page objects should include assertions
themselves, or just provide data for test scripts to do the assertions.”
2. “Advocates of including assertions in page objects say that this helps avoid duplication of
assertions in test scripts, makes it easier to provide better error messages, and supports a
more TellDontAsk style API.”
3. Asserts in Page Objects increase QA Automation window dramatically.
Page Object by Martin Fowler, “assertion” rule

32CONFIDENTIAL
1. “Advocates of assertion-free page objects say that including assertions mixes the
responsibilities of providing access to page data with assertion logic, and leads to a
bloated page object.”
2. “I favor having no assertions in page objects.”
3. “I think you can avoid duplication by using assertion libraries (there is a huge set such a
frameworks) for common assertions - which can also make it easier to provide good
diagnostics.”
Page Object by Martin Fowler, “assertion” rule

33CONFIDENTIAL
1. We've described this pattern in terms of HTML, but the same pattern applies equally well to
any UI technology. I've seen this pattern used effectively to hide the details of a Java swing
UI and I've no doubt it's been widely used with just about every other UI framework out
there too.
2. Patterns that aim to move logic out of UI elements (such as Presentation Model, Supervising
Controller, and Passive View) make it less useful to test through the UI and thus reduce the
need for page objects.
Page Object - notes

34CONFIDENTIAL
1. Page objects are most commonly used in testing, but can also be used to provide a scripting
interface on top of an application.
2. It's best to put a scripting interface underneath the UI, that's usually less complicated and
faster.
3. However with an application that's put too much behavior into the UI then using page
objects may make the best of a bad job. (But look to move that logic if you can, it will be
better both for scripting and the long term health of the UI.)
Page Object – alternative areas of usage

35CONFIDENTIAL
1. Page Element – encapsulates “complexity” of UI element, canonical example – table as a
part of UI.
2. Page Element – the simplest Page Object (Page Object with one and only one UI element)
Page Element

36CONFIDENTIAL
1. Action – a set (tiny or huge) of lines of code based on “primitive” “low level” API (for
example Selenium or some wrapper) calls.
2. Action is usually used in a combination with Page Element and Page Object Design Patterns.
3. Action layer could be separated from, combined with Page Objects layer … or even both
approached in one solution.
Action

37CONFIDENTIAL
1. 2 “types” of Actions:
– QA Automation specialist oriented;
– Business (~Product Owner) oriented;
2. Action – isn’t a right place for asserts in mooooooooost cases:
– There is no sense to check the same functionality in the same build dozens of times;
– Such an approach seriously increase QA Automation windows;
Action

38CONFIDENTIAL
1. QA Automation specialist oriented Action can contain just several lines of code, to simplify
manipulations with Widgets.
2. Business oriented Action can be a “copy” of some test (without all asserts).
3. In general Action layer could be implemented ether as a classical API or as a DSLFlow
based API.
Action

39CONFIDENTIAL
1. Ubiquitous language
– Domain model
– Domain driven design (DDD)
– In fact – really-really useful, general purpose practice, part of fully implemented Agile process
2. Key word driven QA Automation
3. Behavior Driven Development (BDD) approach – as a special case of DSL based QA
Automation solutions
Flow – Fluent Interface, “logical chain”

40CONFIDENTIAL
1. Domain specific language (DSL) based QA Automation
2. Flow – as a way of implementation DSLBDD
3. State-full solution
Flow – Fluent Interface, “logical chain”

41CONFIDENTIAL
1. Flow- fluent interface is an implementation of an object oriented API that aims to provide
more readable code.
2. A fluent interface is normally implemented by using method cascading (concretely method
chaining) to relay the instruction context of a subsequent call (but a fluent interface
entails more than just method chaining).
3. Generally, the context is defined through the return value of a called method self-
referential, where the new context is “equivalent” to the last context terminated through
the return of a void context.
Flow by wiki

42CONFIDENTIAL
Flow – an abstract example
LoginPage.Instance().Navigate()
.Login()
.Search("some entity")
.ClickImages()
.SetSize(Sizes.Large)
.SetColor(Colors.BlackWhite)
.SetTypes(Types.Clipart)
.SetPeople(People.All)
.SetDate(Dates.PastYear)
.SetLicense(Licenses.All);

43CONFIDENTIAL
1. “Building a fluent API like this leads to some unusual API habits.”
2. “One of the most obvious ones are setters that return a value.”
3. “The common convention in the curly brace world is that modifier methods are void, which
I like because it follows the principle of CommandQuerySeparation. This convention does
get in the way of a fluent interface, so I'm inclined to suspend the convention for this
case.”
4. “You should choose your return type based on what you need to continue fluent action.”
5. “The key test of fluency, for us, is the Domain Specific Language quality. The more the use
of the API has that language like flow, the more fluent it is.”
Flow by Martin Fowler

44CONFIDENTIAL
1. DSL = Domain (ether technical or business … or both – Gherkin for specific domain) +
Language
2. Language = Dictionary + Structure
3. Dictionary = Ubiquitous language
4. Structure = some rules how to combine words (business terms) from dictionary in a proper
ways (based on business logic)
5. Way of implementation (one of the ways) – Flow Design Pattern
DSL – Domain Specific Language

45CONFIDENTIAL
1. The basic idea of a domain specific language (DSL) is a computer language that's targeted
to a particular kind of problem (QA Automation or even QA Automation in exact domain),
rather than a general purpose language that's aimed at any kind of software problem.
Domain specific languages have been talked about, and used for almost as long as
computing has been done.
2. DSLs are very common in computing: examples include CSS, regular expressions, make,
rake, ant, SQL, HQL, many bits of Rails, expectations in JMock …
3. It's common to write tests using some form of DomainSpecificLanguage, such as Cucumber
or an internal DSL. If you do this it's best to layer the testing DSL over the page objects so
that you have a parser that translates DSL statements into calls on the page object.
DSL by Martin Fowler

46CONFIDENTIAL
1. Internal DSLs are particular ways of using a host language to give the host language the
feel of a particular language. This approach has recently been popularized by the Ruby
community although it's had a long heritage in other languages - in particular Lisp. Although
it's usually easier in low-ceremony languages like that, you can do effective internal DSLs
in more mainstream languages like Java and C#. Internal DSLs are also referred to as
embedded DSLs or FluentInterfaces
2. External DSLs have their own custom syntax and you write a full parser to process them.
There is a very strong tradition of doing this in the Unix community. Many XML
configurations have ended up as external DSLs, although XML's syntax is badly suited to
this purpose.
3. Mixed (internal with external)
4. Graphical DSLs requires a tool along the lines of a Language Workbench.
DSL types by Martin Fowler

47CONFIDENTIAL
1. Navigator (for Web) – follows “DRY” and “Single source of truth” principles, encapsulates
“complexity” of links transitions between web pages and store this information in one and
only one place.
2. Usually:
– works in a combination with a “Page Object” and “Action” Design Patterns for QA Automation;
– “Action” layer implements via Flow or DSL approaches;
– state-full approach;
– applies for really big projects.
Navigator (for Web)

48CONFIDENTIAL
1. “If you have WebDriver APIs in your test methods, You're Doing It Wrong.” - Simon Stewart
2. Don't repeat yourself (DRY): “Every piece of knowledge must have a single, unambiguous,
authoritative representation within a system” - Andy Hunt and Dave Thomas in their
book The Pragmatic Programmer
3. “Broken windows theory”
3 “main” principles “rules” 

49CONFIDENTIAL
This is a principle that helps people
remember that object-orientation is about
bundling data with the functions that operate
on that data. It reminds us that rather than
asking an object for data and acting on that
data, we should instead tell an object what
to do. This encourages to move behavior into
an object to go with the data.
“Tell-Don't-Ask” principle

50CONFIDENTIAL
1. “Test-driven development”
2. “Single responsibility principle”
3. “Single source of truth”
4. “Interface segregation principle”
5. “Occam's razor”
6. “Poka-yoke”
Useful “principles”

81CONFIDENTIAL
Thanks for your attention
Anton Semenchenko
EPAM Systems
www.comaqa.by
www.corehard.by

Design Patterns for QA Automation

More Related Content

Design Patterns for QA Automation