What you'll learn:
- Design Patterns In Test Automation
- Clean Reusable Page object design & Frameworks
- Single Responsibility Principle
- Factory Pattern
- Strategy Pattern
- Command Pattern
- Template Method Pattern
- Proxy Pattern
- Execute Around Method Pattern
- Decorator Pattern
Design Patterns are repeatable and reusable solutions for software design related issues.
This course helps you to get introduced to the some of the frequently used Design Patterns among Software developers and demo how we can use them in Test Automation to achieve better re-usability and maintainability in the your Automation Framework, Page Objects & Test classes design!
You would learn following Design Principles and Design Patterns.
Single Responsibility Principle: Each and every module, class, method in an application should have only one specific responsibility to handle. Using this we could refactor our complex Pages Objects into multiple modular Page Components or Page Fragments and we could write very neat test steps.
Factory Pattern: We should be able to create an object without exposing the creation logic to the test class. For ex: Lets consider the localization testing in which we need to test multiple languages for an app. This app might have a language specific behavior as well. We can have an abstract class with common functionalities and language specific sub classes. We can use Factory Pattern to create specific Page Object based on the language we test!
Strategy Pattern: We should be be able to pass the behavior to an object at run time. For ex: Google search page might have different search strategies. Text based search or voice based search. We have a Page Object for google search page and different components for search strategies. We should be able to pass specific strategy at run time w/o writing ugly if-else blocks.
Command Pattern: An object is encapsulated with all the information required to run this at a later stage when required. It would be very useful for a Page with multiple UI components with a lots of UI validations.
Template Method Pattern: A super class defines a high-level steps/skeleton and all the sub classes override the steps. For ex: An application for room booking and car booking will have similar workflow but with different options. This Pattern explains how to create better Page Objects using this pattern.
Proxy Pattern: A placeholder object for another object. For ex: You want to execute some steps on QA environment and want to skip same steps on PROD environment because we might not be allowed to execute those steps. This pattern helps you to write such cases in a much better way.
Execute Around Method Pattern: Sometimes we might have to do some steps always. For ex: To read a file, open a file, read and close. To write content into a file, open a file, write and close. If you see, opening and closing file steps are common and should be done always irrespective of reading or writing content into a file. This pattern explains how to write such steps in a better way.
Decorator Pattern: Some times an application will have different UI components depends on the user role. An admin role will have all the access. A user role will have limited access etc. How to create such page objects based on user roles. This is what this pattern is about.
Note: This course does not have captions enabled.
