In my previous articles from the series “Design Patterns in Automated Testing“, I explained in details how to make your test automation framework better through the implementation of Page Objects, Facades, and Singletons. When we have to write tests for more complex use case scenarios, it gets usually harder and harder to follow the Open Close Principle, one of the primary principles part of SOLID. In this part of the series, I am going to use the Strategy Design Pattern to create extendable validators for an E-Commerce module.



Definition computer programming, the strategy pattern (also known as the policy pattern) is a software design pattern that enables an algorithm ‘ s behavior to be selected at runtime. Defines a family of algorithms.

Encapsulates each algorithm.

Makes the algorithms interchangeable within that family.

The code is easier to maintain as modifying or understanding strategy does not require you to understand the whole main object. In, the(also known as the) is athat enables ans behavior to be selected at runtime.

UML Class Diagram

Participants

The classes and objects participating in this pattern are:

IStrategy (IOrderValidationStrategy) – Defines an interface common to all algorithms. The context class calls the interface to perform the algorithm, identified by the concrete strategy.

(IOrderValidationStrategy) – Defines an interface common to all algorithms. The context class calls the interface to perform the algorithm, identified by the concrete strategy. ConcreteStrategy (SalesTaxOrderValidationStrategy)- Implements the algorithm using the strategy interface.

(SalesTaxOrderValidationStrategy)- Implements the algorithm using the strategy interface. Context (PurchaseContext) – Holds a dependency to IStrategy. Wraps the calls to the concrete strategies, may provide an interface to the strategies to access its data.

Strategy Design Pattern C# Code

Test’s Test Case

The primary goal of the below tests is going to be to purchase different items from Online Store. Also, the prices on the last step of the buying process should be validated- taxes, shipping costs, gift wrapping expenses, etc.

1. Navigate to Item’s Page

2. Click Proceed to Checkout

3. Login with an existing Client



4. Fill Shipping Info

5. Choose a shipping speed

6. Select a payment method



7. Validate the Order Summary



The primary goal of the design of the test related classes is to enable a decoupled and extendable validation of the different prices on the last page of the purchasing process.

The following class structure is going to be used.

As you can see, the design of the tests uses heavily Page Object Pattern. There is nothing unusual in the different pages, so I’m not going to paste the code of every single page here because it is not relevant to the articles’ theme. Probably, the most interesting logic is located in the ShippingAddressPage.

The ClientPurchaseInfo class holds the data about the client’s purchase, most of the data is populated through string properties.

Implementation without Strategy Design Pattern

The use cases can be automated easily via the usage of Facade Design Pattern.

The main drawback of such solution is the number of different methods for the different tax verification cases. If there is a need to introduce a new tax validation, a new method should be added that is going to break the Open Close Principle.

For more detailed overview and usage of many more design patterns and best practices in automated testing, check my book “Design Patterns for High-Quality Automated Tests, C# Edition, High-Quality Tests Attributes, and Best Practices“. You can read part of three of the chapters:

Defining High-Quality Test Attributes for Automated Tests

Benchmarking for Assessing Automated Test Components Performance

Generic Repository Design Pattern- Test Data Preparation

Strategy Design Pattern Implementation

There are hundreds of test cases that you can automate in this sample e-commerce module. Some of the most important are related to the correctness of the prices on the last page of the purchasing process. So the primary goal of the validations in the tests is going to be to test if the correct prices are displayed. There is a couple of types of taxes- Sales (US/Canada), VAT (EU Union Countries), Gift Wrapping, Shipping, etc. The page objects can be combined in the PurchaseContext class to perform a new purchase, the strategy design pattern can be applied to pass the specific validation strategy.

The main method of the validation strategy can be defined by the following interface.

The PurchaseContext class is almost identical to the already discussed facade classes; the only difference is that it holds a dependency to the to the IOrderValidationStrategy.

The concrete validation strategy is passed to its constructor.

In most cases, I believe that the best approach to validate taxes and similar money amounts is to call the real production web services that are used to power the actual e-commerce module. They should be already entirely tested via unit and integration tests, and their output should be guaranteed.

The primary goal of the E2E tests is to ensure that the correct prices are visualized on the page rather than to check the real calculation logic. So in my concrete implementation of the SalesTaxOrderValidationStrategy, I have created a dummy sample implementation. In actual tests instead of calculating the taxes manually, we should call the production web service. If the module doesn’t use web services, you can always create your test web-service and call the production code in wrapper methods. I had already done that for an old legacy module that I had to validate automatically.

I have implemented a similar logic for the VAT Tax Validation Strategy.

One of the essential benefits of the usage of the Strategy Design Pattern is that if a new tax is introduced in the application, you don’t have to modify your existing pages or the PurchaseContext. You will need only to create a new concrete strategy.

For example, if Online Store announces that from tomorrow a super model can deliver you the desired items directly to your door, only for 100 bucks. You can handle the new tax validation by creating a new SuperModelOrderValidationStrategy.

Tests Using Strategy Design Pattern

The use of the Strategy Design Pattern to create automated tests is easy. The only thing that you have to do is to pass the desired algorithm to the newly created PurchaseContext.