In my last publication from the Design Patterns in Automated Testing Series, I explained to you how you can benefit from the usage of the Specification Design Pattern. In short your business rules can be recombined by chaining them together using boolean logic. The pattern increases the reusability, maintainability, readability and leads to loose coupling of the business rules from the business objects. In this article, I am going to extend the idea about it even more. I am going to show you how you can configure the rules through LINQ syntax, exchange the base specification class with extension methods. Further, you will learn how to decouple the specifications from the page objects through the usage of test context objects.

Simplify Basic Specification Design Pattern with Extension Methods

Basic Specification Design Pattern UML Class Diagram

Basic Specification Design Pattern Participants

The classes and objects participating in Specification Design Pattern are:

ISpecification – Defines the interface for all specifications.

– Defines the interface for all specifications. Specification – An abstract class that contains the implementation of the And , Or and Not methods. Only the IsSatisfiedBy varies based on the business rule.

– An abstract class that contains the implementation of the , and methods. Only the varies based on the business rule. AndSpecification – Specification class used for chaining purposes defines the “And” boolean operator.

– Specification class used for chaining purposes defines the “And” boolean operator. OrSpecification – Defines the “ Or ” boolean operator.

– Defines the “ ” boolean operator. NotSpecification – Defines the “ Not ” boolean operator.

– Defines the “ ” boolean operator. CreditCardSpecification– A concrete specification where the IsSatisfiedBy method is implemented. Holds the concrete business rule.

Extension Methods’ Specification Design Pattern UML Class Diagram

Extension Methods’ Specification Design Pattern Participants

The classes and objects participating in Specification Design Pattern are:

ISpecification – Defines the interface for all specifications.

– Defines the interface for all specifications. SpecificationExtensionMethods – A static class that contains the implementation of the And , Or and Not methods as static extension methods.

– A static class that contains the implementation of the , and methods as static extension methods. AndSpecification – Specification class used for chaining purposes defines the “And” boolean operator.

– Specification class used for chaining purposes defines the “And” boolean operator. OrSpecification – Defines the “ Or ” boolean operator.

– Defines the “ ” boolean operator. NotSpecification – Defines the “ Not ” boolean operator.

– Defines the “ ” boolean operator. CreditCardSpecification– A concrete specification where the IsSatisfiedBy method is implemented. Holds the concrete business rule.

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

Extension Methods’ Specification Design Pattern C# Code

The subtle difference between the basic Specification Design Pattern and the later is that the abstract Specification class is removed. The concrete specification classes implement the ISpecification<TEntity> directly. The logic of the abstract Specification base class is moved to extension methods in the static SpecificationsExtensionMethods class.

It is not a big change but this way you simplify the inheritance chain. However, this is not the intended usage of the extension methods so you should carefully analyse the pros and cons of the approach.

LINQ Specification Design Pattern

LINQ Specification Design Pattern UML Class Diagram

LINQ Specification Design Pattern Participants

The classes and objects participating in LINQ Specification Design Pattern are:

ISpecification – Defines the interface for all specifications.

– Defines the interface for all specifications. Specification – An abstract class that contains the implementation of the And , Or and Not methods. Only the IsSatisfiedBy varies based on the business rule.

– An abstract class that contains the implementation of the , and methods. Only the varies based on the business rule. ExpressionSpecification– The class eliminates the need for concrete specifications. It accepts a boolean function as a parameter which represents the business rule.

LINQ Specification Design Pattern C# Code

ISpecification and Specification stay the same as in the basic implementation of the pattern. You can find their code in my previous article about the Specification Design Pattern. As stated above the need of the concrete specifications is eliminated through the introduction of the new ExpressionSpecification class.

The expression variable holds the core business rule, passed as a C# Func parameter (LINQ expression) to the constructor.

We can initialize the new type of specifications directly in the page object’s constructor.

Unfortunately, as the expression specifications’ variables are declared as private, we cannot reuse them in the page’s asserter. I am going to show you how to refactor the code to fix the mentioned issue.

Improve LINQ Specification Design Pattern with Test Context

To be able to reuse the expression specifications, their configurations and chaining, we need to create two new classes. OrderTestContextConfigurator is going to expose the specifications as public properties. It is going to be responsible for their setup. This way the page objects follow the Single Responsibility Principle more strictly as they won’t be responsible for this configuration anymore, they will provide only service methods.

You can reuse the specifications even only with the help of this class. Мake the specifications public properties of the page objects or pass them as parameters to the asserts. However, we can extend the reuse even more. Even if you expose them as public properties, you cannot reuse their chaining rules. We can create a new special class called

So we can create a new specially designed class called OrderTestContext. It will hold the required input information for the order completion process- the purchase test input and two boolean properties.

Through its usage, you can reuse the business rules and their chaining logic. It is up to you if you will expose it as a public property of the page object or pass it always as a parameter.