The document discusses automation best practices for complex UI testing, outlining strategies for simplifying test scenarios through the use of test doubles and design patterns. It emphasizes the importance of reducing scenario duplication, managing complex architecture, and enhancing test clarity and maintainability. Additional resources and insights on test methodologies and personal experience in automation engineering are also provided.

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