This talk is a brief overview of how we deal with UI test architecture on our project. Complex backend, SPA as a frontend, 20+ different brands and 100+ features for each, more and more code. We will discuss: – fakes and test doubles, approaches how to build and maintain them; – development patterns, which help you to make your architecture more simple, stable and readable; – tips and tricks – how to make your life with UI tests easier.

1. An easy way to
automate complex UI
Test automation practices and tips

2. About me
 7+ years in IT
 Automation Engineer
 Scrum Master
 Betsson project, Ciklum


3. What we have
 Payments Solution for online casino
 20+ brands
 7+ countries
 40+ payment methods
 Payment Pages UI (Desktop, mobile, adaptive)
 Brand specific features

4. Complex UI?*
*from automation perspective

5. Complex UI?
 Complex fronted:
 Dynamic
 Async
 Adaptive
 Complex backend:
 Hardly configurable
 Overflown
 Slow
 Unstable

6. Complex tests
 Complex behavior
 Complex architecture
 Slow
 Fragile
 Overflown with scenario's
 «Test smells» *
 *http://xunitpatterns.com/TestSmells.html

7. What automation we want?
 Easy to write
 Clear to understand
 Simple to work with

8. Agenda
 Fakes & test doubles
 Test & Patterns
 Tips and tricks (test sugar & screenshots)

9. Fakes & test doubles

10. Test doubles
 We replace a component on which the SUT
depends with a "test-specific equivalent.“
 Test Stub
 Mock Object
 Fake Object

11. Test doubles
 Web part
 WebApi
 Core System
 DB
 3rd systems

12. Test doubles
 Web part
 WebApi / Fake
 Core System
 DB
 3rd systems

13. 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

14. Static Fake
 Static Fake – hardcoded behavior of dependent
component.

15. Static Fake. Pros
 Have all specific behaviors
 Any language for implementation*
 Use for prototyping & local testing
 Speedup tests
 *Sometimes it very hard to mock backend on JavaScript

16. Static Fake. Cons
 It is not easy to implement
 Test scenarios are not clear
 Support

17. 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.

18. Dynamic Fake. Pros
 Have all specific behaviors
 Configured from test
 Scenarios are clear & readable

19. Dynamic Fake. Cons
 Much harder for development
 Can’t/hard to used for prototyping or local testing

20. Pitfalls
 Fake – not a silver bullet
 Additional test layer:
Contract tests on fake/depended
component
 Do not test Fake, test SUT

21. Tests and Patterns

22. Tests & Patterns. Problems
 Scenarios duplicates
 Overflown locators / base classes /behavior
 Tones of code
 Inheritance hell

23. 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

24. PageFactory

25. Common Naming
 XPath and component @data-name attribute
 Result: ~ -35% PageObject duplicates.
 Similar payment method pages are not duplicated

26. 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

27. Template Method
 Behavioral interfaces for each component
IReceiptPage 
BankReceiptPage|WizardMobileReceiptPage|..
ReceiptPageBase – with complex step definition
 Result:
Logic encapsulated from base class to each
component implementation

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

29. Strategy Pattern

30. 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

31. Tests & Patterns
 Scenarios duplicates
 Overflown locators /
base classes /behavior
 Tones of code
 Inheritance hell
 Factories
 Common naming
 Patterns
 Template method
 Strategy

32. Tests sugar. Screenshots

33. Test sugar
 SpecFlow & Given-When-Then structure
 Given - only preconditions
 When - all actions
 Then - only asserts

34. Screenshots on each test step

35. Screenshots in tests
 SpecFlow [AfterStep]
 Screenshot all steps
 Keep history

36. Screenshots. Visual testing
 Use extra step
 Continue on failure
 Use emulations
 Hardcode/Ignore dynamic values

37. How to make your life easier?
 Fake complex backend
 Simplify your architecture
 apply patterns
 use best practices
 Improve test feedback – use text, visual
information

38. What automation we get?
 Easy to write
 Clear to understand
 Simple to work with

39. That's all folks!
Questions?

40. Links
Test Doubles:
• http://xunitpatterns.com/Test%20Double.html
• https://www.martinfowler.com/bliki/TestDouble.html
Patterns:
• https://sourcemaking.com/design_patterns/behavioral_patterns
Me (Ivan Pashko):
• https://www.facebook.com/groups/1180099188730673/
Pictures:
• https://pixabay.com | https://unsplash.com