In my last article “Strategy Design Pattern“, I explained the benefits of the application of Strategy Design Pattern in your automation tests. Some of the advantages are more maintainable code, encapsulated algorithm logic, easily interchangeable algorithms and less complicated code.

In this part of the series, I’m going to extend my ideas about the application of the Strategy Design Pattern in automation tests. In my previous examples, I presented to you code samples where the tests used only one strategy at a time. Here I’m going to show you how to apply the pattern so that you will be able to use multiple strategies at once. Another advanced usage that I want to demonstrate is the use of the Strategy Design Pattern, to validate the tests prerequisites.

If you are not familiar with the above patterns, I suggest you to read my articles about them first, to be able to understand the presented concepts thoroughly.

Advanced Strategy Design Pattern C# Code

Test’s Test Case

The test case of the examples is going to be the same as of the previous article. The primary goal 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 difference between this article’s examples and the previous ones is going to be that there is a need sometimes to mix multiple strategies in one test. For instance buy an Online Store item with different billing and shipping info and so paying VAT and Sales taxes in a single purchase. Or even add a gift wrap to the same shopping cart. In my last post’s examples, these operations have been isolated in different strategy classes. The primary goal of today’s refactoring is going to be to extend the code to be able to operate with multiple strategy classes at once.

I have slightly modified the strategy interface with the addition of a new validation method.

This method is going to be used to validate the test prerequisite data passed to the pattern’s class. In SalesTaxOrderPurchaseStrategy if the shipping country is not United States an ArgumentException is thrown because the other methods of the class won’t be meaningful. The sales tax is applicable only for US.

The same logic is implemented in the VatTaxOrderPurchaseStrategy, GiftOrderPurchase strategies. The only addition to these classes is the ValidateClientPurchaseInfo method. It can be used to validate that your strategies are utilized in the correct manner. There are a lot of companies where quality assurance automation engineers write the core framework (strategies, context classes) while the tests are written by less technical people. So such preventative measures can be considered in cases like that.

Reconstruct Text Strategies Context

First Version Basic Strategy Design Pattern Applied

Improved Version Advanced Strategy Design Pattern Applied

There are a couple of significant changes in the above code compared to the first version. The most prominent one is that the strategies instances are now stored in an array.

An unspecified count of strategies can be passed to the constructor of the class as a result of the usage of the params parameter.

Two new methods are added, where for each registered strategy a particular method is executed. If you pass two strategies, their two methods are going to be performed successively.

The ValidateClientPurchaseInfo is called for each strategy so that if there are any misconfigured data, it is going to throw an ArgumentException.

Advanced Strategy Design Pattern- Usage in Tests

The usage of the advanced strategy design pattern in tests stays as smooth as before but now you can use multiple strategies combined.

First Version Basic Strategy Pattern Applied

In the first version has been possible to pass only a single instance of the IOrderValidationStrategy.

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

Improved Version Advanced Strategy Design Pattern Applied

Here you are able to mix multiple strategies- SalesTaxOrderPurchaseStrategy, VatTaxOrderPurcahseStrategy, GiftOrderPurchaseStrategy. If you have to add new strategies to your logic, it is going to be easy to plug them in the existing design. Also, you won’t have to modify the Context class because of the usage of the IOrderPurchaseStategy array and the params parameter.

As a consequence of these actions, your tests’ architecture will follow the Open Close Principle, which states that the code should be open for extension but closed for modification.