Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Design patterns in test automation


Published on

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.

Published in: Technology
  • Login to see the comments

Design patterns in test automation

  1. 1. Design patterns in test automation Mikalai Alimenkou @xpinjection
  2. 2. Disclaimer This talk is based on personal experience
  3. 3. Design pattern? What is it?
  4. 4. Classical Design Patterns
  5. 5. Main driver is *ity Test Logic Application Driver Test Data Reliability Clarity Flexibility Maintainability Stability
  6. 6. 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.
  7. 7. Index Page Main Page login Search Page search filter ordersearch Details Page open see more show me like this close #1. Page Object
  8. 8. Page structure
  9. 9. Available methods
  10. 10. #2. Fluent/Chain of invocations
  11. 11. #3. Factory/Page Factory
  12. 12. #4. Page Element/Composite List of Items Link Menu Panel Checkbox
  13. 13. No duplicated code
  14. 14. #5. Loadable Component
  15. 15. #6. Strategy • Validation • Navigation • Calculation • Execution
  16. 16. 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.
  17. 17. #7. Value Object
  18. 18. #8. Builder
  19. 19. #9. Assert Object/Matchers
  20. 20. #10. Data Registry
  21. 21. #11. Object Pool/Flyweight • DB instance • Browser • Pages • Heavy domain objects
  22. 22. #12. Data Provider
  23. 23. Entity Driven Data Provider
  24. 24. 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.
  25. 25. #13. Decorator Driver in driver in driver in driver in driver in driver in driver in driver in driver…
  26. 26. #14. Proxy
  27. 27. 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
  28. 28. 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.
  29. 29. #15. Keyword Driven Testing
  30. 30. #16. Behavior Specification
  31. 31. Behavior Driven Development
  32. 32. #17. Steps
  33. 33. WebDriver or Pages inside
  34. 34. Steps is a key for success Acceptance tests Page Objects
  35. 35. Steps in different formats = Testing scenario WebDriver test
  36. 36. @xpinjection