Design patters exist for years in software development. Some developers love them, some think they are useless. But design patters has very clear goals: describe common solutions for common problems, create shared language for community, improve understanding and reuse of existing approaches. Test automation has its own set of problems, so there is a set of helpful design patterns for this area. In this talk I will run through all known patterns and describe them in details with several practical samples.

1. Design patterns in test
automation
Mikalai Alimenkou
http://xpinjection.com
@xpinjection

4. Disclaimer
This talk is based on
personal experience

5. Design pattern? What is it?

6. Classical
Design
Patterns

7. Main driver is *ity
Test
Logic
Application
Driver
Test
Data
Reliability
Clarity
Flexibility
Maintainability
Stability

8. Structural Patterns
Structure test code better to improve
maintainability, avoid duplicates and separate
concepts, so it becomes easier for test engineer
to understand, change and support tests.

9. Index
Page
Main
Page
login
Search
Page
search
filter
ordersearch
Details
Page
open
see more
show me like this
close
#1. Page Object

10. Page structure

11. Available methods

12. #2. Fluent/Chain of invocations

13. #3. Factory/Page Factory

14. #4. Page Element/Composite
List of Items
Link
Menu
Panel
Checkbox

15. No duplicated code

16. #5. Loadable Component

17. #6. Strategy
• Validation
• Navigation
• Calculation
• Execution

18. Data Patterns
Separate data management from test logic
and reduce amount of data related boilerplate
code in tests, making logic more clear and
maintainable for test engineers.

19. #7. Value Object

20. #8. Builder

21. #9. Assert Object/Matchers

22. #10. Data Registry

23. #11. Object Pool/Flyweight
• DB instance
• Browser
• Pages
• Heavy domain objects

24. #12. Data Provider

25. Entity Driven Data Provider

26. Technical Patterns
Keep technical aspects separately from test
logic if some additional level of control or low
level data is needed, reducing tests complexity
and improving test code maintainability.

27. #13. Decorator
Driver in driver in
driver in driver in
driver in driver in
driver in driver in
driver…

28. #14. Proxy

29. Use HTTP proxy for tests
• Blacklist external resources (Facebook, Twitter, Ads,
etc.)
• Cache images and other nonfunctional resources
• Collect HTTP traffic for analysis (404, redirects,
loading time, etc.)
• Speedup page loading

30. Business Involvement Patterns
Try to bring business people and
requirements as close as possible to test
automation, making it more valuable and
helpful for the whole product team.

31. #15. Keyword Driven Testing

32. #16. Behavior Specification

33. Behavior Driven Development

34. #17. Steps

35. WebDriver or Pages inside

36. Steps is a key for success
Acceptance
tests
Page
Objects

37. Steps in different formats
=
Testing
scenario
WebDriver
test

39. @xpinjection
http://xpinjection.com
mikalai.alimenkou@xpinjection.com