Selenium Design Patterns
- 2. About me ï” Test automation expert ï” Extensive experience in BDD, TDD, SpecFlow and Selenium. ï” QA and Automation leader at BurlingtonEnglish, ï” Blogger at SeleniumPro.net
- 3. Clean Code âAny fool can write code that a computer can understand. Good programmers write code that humans can understand.â - Martin Fowler
- 4. Clean Code âGood code isn't just readable by a machine, but by humans as wellâ Martin Fowler
- 5. What is Clean Code ï” A reader-focused development style that produces software thatâs easy to write, read, and maintain ï” Clean code is code that is easy to understand and easy to change
- 6. Why Clean Code Matters ï” Each line of code is likely to be read many times by humans during its lifetime ï” Maintenance: Writing code is relatively easy, reading is hard, by creating code that is maintainable, you are optimizing the majority of your time and the cost of maintaining code
- 7. Simplicity: By keeping your code simple, you can produce higher quality code, solve problems faster ,and work better in groups When your code is indented, it becomes more readable and easier to find what youâre looking for Cost Savings: By doing clean code, you gain all those advantages listed above, and all of them lead to cost savings.
- 9. Code Smells ï” Code Smell is a term coined by Kent Beck and introduced in Martin Fowler's book, Refactoring. ï” Code Smells are patterns of code that suggest there might be a problem ï” There might be a better way of writing the code or that more design perhaps should go into it ï” Anti Patterns describes the same kinds of phenomena
- 10. Examples for Code Smells ï” Alternative Classes with Different Interfaces (should probably be refactored to have similar interfaces) ï” Comments (code should be written so that the comments are not necessary) ï” Duplicate Code - If you see the same code structure in more than one place, you can be sure that your program will be better if you find a way to unify them ï” See Don't Repeat Yourself ï” Large Class - Single responsibility principle - every module or class should have responsibility over a single part of the functionality provided by the software ï” Long Method - The longer a function is, the more difficult it is to understand. ï” Long Parameter List - More than three arguments to a function is generally an issue
- 11. Common bad patterns of Selenium code ï” Writing Selenium code inside tests ï” Sleep ï” Not making tests independent of each other ï” Name your tests wisely - Naming convention ï” Reuse components. Donât Copy/paste ï” Testing more that 1 thing in a single test: Single purpose tests are easier to create and maintain ï” Not following AAA pattern (Arrange => Act => Assert) ï” Not using PageObjects / ScreenPlay patterns
- 12. More bad practices related to Selenium tests ï” PageObject with public WebElements ï” Static driver (singleton) ï” Unstable locators ï” Long PageObject class (Code SmellâŠ)
- 13. Page Objects ï” Page Object is a design pattern for building robust, reusable and maintainable automated GUI tests, Page Object is very popular, especially with Selenium tests ï” This pattern helps you to organize your code, makes your code much more readable, reusable and maintainable
- 15. Why Page Objects Pattern ï” Avoid code duplication ï” Improve readability ï” Organize code for web pages interaction ï” Saves a lot of time on tests maintenance and makes the UI automation pipeline faster => reduces costs
- 16. Page Objects can become anti-pattern called âLarge Classâ ï” This happens when you have too many elements on some of the pages ï” so the number of functions on an object that represents the page might become really huge ï” This goes against one of the most important design principles in object- oriented programming called SOLID ï” Single Responsibility Principle ï” Open Closed Principle ï” Liskov Substitution Principle ï” Interface Substitution Principle ï” Dependency Inversion Principle
- 17. Single Responsibility Principle ï” Each class should have a single functionality ï” A class should have only one reason to change. - Robert C. Martin
- 18. Solution: Design OOP Page Objects Example 1: Email Inbox Instead of:
- 20. Example 2: Todos Application
- 22. Task Row:
- 23. And the usage:
- 24. Usage of Todos page:
- 26. The Screenplay Pattern ï” Screenplay is the design pattern for acceptance tests ï” Allows you to easily follow SOLID principles
- 28. And the classes: For more information: https://dzone.com/articles/page-objects- refactored-solid-steps-to-the-screenp
- 29. Conclusions: ï” By modeling the page components into objects we will prevent ourselves from large classes, ï” It seems that by using ScreenPlay pattern there will be tons of classes ï” ScreenPlay is preferred over large page objects ï” Small PageObject classes are much better than ScreenPlay design
- 30. Flaky tests ï” We define a "flaky" test result as a test that exhibits both a passing and a failing result with the same code ï” Non-deterministic tests have two problems: ï” Firstly - they are useless ï” Secondly - they are a virulent infection that can completely ruin your entire test suite. ï” As a result they need to be dealt with as soon as you can, before your entire deployment pipeline is compromised.
- 31. Reasons for flaky tests and How to prevent them ï” Testsâ Initial State Should Always be Consistent â See Oren Rubin great article here ï” Avoid non deterministic input â A test should run exactly the same with given parameters. ï” Test should be deterministic â with the same conditions, avoid âifâ in the tests ï” Test with many âifâ conditions or other non deterministic conditions - will be very hard to know the exact workflow that happened when the test was failed
- 32. More reasons for flaky tests in Selenium tests: ï” Not following Page Object pattern principle of verifying in the constructor of a PageObject class that the page was loaded, this or other similar issues can cause that sometime the operation happened to early so it failed. ï” Use Assert methods with waiting logic, because sometimes the same assertion will pass after waiting a little bit ï” Flaky third party code
- 33. Tips for parallel tests architecture ï” Use different data as possible (users, etc.) ï” Each test should use his own objects ï” Try to minimum the usage of static resources ï” If need static / singleton â write thread safe code, with thread safe collections, lock if needed, etc.