An easy way to automate complex UI

Test automation practices and tips

About me

7+ years in IT Automation Engineer Scrum Master Betsson project, Ciklum

What we have

Payments Solution for online casino 20+ brands 7+ countries 40+ payment methods Payment Pages UI (Desktop, mobile,

adaptive) Brand specific features

Complex UI?*

*from automation perspective

Complex UI? Complex fronted:

Dynamic Async Adaptive

Complex backend: Hardly configurable Overflown Slow Unstable

Complex tests

Complex behavior Complex architecture Slow Fragile Overflown with scenario's «Test smells» *

*http://xunitpatterns.com/TestSmells.html

What automation we want?

Easy to writeClear to understandSimple to work with

Agenda

Fakes & test doubles Test & Patterns Tips and tricks (test sugar & screenshots)

Fakes & test doubles

Test doubles

We replace a component on which the SUT depends with a "test-specific equivalent.“

Test Stub Mock Object Fake Object

Test doubles

Web partWebApiCore SystemDB3rd systems

Test doubles

Web partWebApi / FakeCore SystemDB3rd systems

What can we solve with Fake

Test without dependent components … without Backend… without 3rd Party services… without DB

Test unavailable component Simplify scenarios precondition Fix Slow/ Fragile / Heavyweight tests

Static Fake

Static Fake – hardcoded behavior of dependent component.

Static Fake. Pros

Have all specific behaviorsAny language for implementation*Use for prototyping & local testingSpeedup tests

*Sometimes it very hard to mock backend on JavaScript

Static Fake. Cons

It is not easy to implementTest scenarios are not clearSupport

Dynamic Fake

Configurable Fake Object - a reusable Test Double with the configurable values to be returned or verified during the fixture setup phase of a test.

Dynamic Fake. Pros

Have all specific behaviorsConfigured from testScenarios are clear & readable

Dynamic Fake. Cons

Much harder for developmentCan’t/hard to used for prototyping or local

testing

Pitfalls

Fake – not a silver bulletAdditional test layer:

Contract tests on fake/depended component

Do not test Fake, test SUT

Tests and Patterns

Tests & Patterns. Problems

Scenarios duplicates Overflown locators / base classes /behavior Tones of code Inheritance hell

PageFactory

PageFactory + [Attributes] Factory return needed page based on SiteName, PaymentMethod,

IsMobile No new for Page Object creation Fallback (from brand to common)

Result: ~ -55% duplicates in test scenarios. Test request needed page from Factory (same method for all

brands) Test prepares and transmits data to PageObject

PageFactory

Common Naming

XPath and component @data-name attribute

Result: ~ -35% PageObject duplicates. Similar payment method pages are not duplicated

Template Method

Define the skeleton of an algorithm in an operation, deferring some steps to client subclasses.

Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure

Template Method

Behavioral interfaces for each componentIReceiptPage BankReceiptPage|

WizardMobileReceiptPage|..ReceiptPageBase – with complex step definition

Result: Logic encapsulated from base class to each

component implementation

Strategy Pattern

Strategy pattern - enables an algorithm's behavior to be selected at runtime.

Strategy Pattern

Strategy Pattern

Strategy pattern on element-component: IMonthYearComponent

Select2MonthYearComponent| SelectMonthYearComponent | InlineMonthYearComponent

PageFactory init strategy context

Result: ~ -60% duplicates in PageObjects All Brand-specific features overrides were

removed

Tests & Patterns

Scenarios duplicates

Overflown locators / base classes /behavior

Tones of code Inheritance hell

Factories Common naming Patterns

Template methodStrategy

Tests sugar. Screenshots

Test sugar

SpecFlow & Given-When-Then structure Given - only preconditions When - all actions Then - only asserts

Screenshots on each test step

Screenshots in tests

SpecFlow [AfterStep] Screenshot all steps Keep history

Screenshots. Visual testing

Use extra step Continue on failure Use emulations Hardcode/Ignore dynamic values

How to make your life easier?

Fake complex backend Simplify your architecture

apply patterns use best practices

Improve test feedback – use text, visual information

What automation we get?

Easy to writeClear to understandSimple to work with

That's all folks! Questions?

LinksTest Doubles:• http://xunitpatterns.com/Test%20Double.html• https://www.martinfowler.com/bliki/TestDouble.htmlPatterns:• https://sourcemaking.com/design_patterns/behavioral_patternsMe (Ivan Pashko):• https://www.facebook.com/groups/1180099188730673/Pictures:• https://pixabay.com | https://unsplash.com