If you are a regular reader of Automate The Planet you have most probably read some of my articles about Design Patterns in Automated Testing. The newest article from the famous series is dedicated to the Null Object Design Pattern. I am going to explain how to use the pattern to create a default behavior for your strategies and achieve a cleaner and more concise tests' code. Less branching in the code means lower complexity.

Definition In object-oriented computer programming, a Null Object is an object with no referenced value or with defined neutral ("null") behavior. The Null Object Design Pattern describes the uses of such objects and their behavior (or lack thereof). Rid program logic of null checks where possible

Provide a non-functional object in place of a null reference

Allow methods to be called on Null objects, unlike a null reference

UML Class Diagram

Participants The classes and objects participating in Null Object Design Pattern are: IPurchasePromotionalCodeStrategy - Defines the interface for all strategies.

- Defines the interface for all strategies. UiPurchasePromotionalCodeStrategy - The strategy that is responsible for applying and asserting promotional codes through the UI of the application.

- The strategy that is responsible for applying and asserting promotional codes through the UI of the application. NullPurchasePromotionalCodeStrategy - The null implementation of the strategy interface, provides the default implementation when no promotional code is applied. Null Object Design Pattern C# Code Test's Test Case As in most of the examples from the series, we are going to automate a shopping cart process, the Online Store's one in particular. I am not going to explain the whole process, you can check the full explanations in my articles dedicated to the Strategy Design Pattern. The page that is interesting for us is the last page from the purchase process- Place Order Page. There you can apply promotional codes and gift cards.

The main idea is that sometimes we need to add promotional codes and then assert that the correct amounts are displayed or saved in the DB. As you can assume there are various ways to accomplish that. One way is to use the UI directly and assert the text present in the labels. Another way is to use a direct access to the DB and insert the promotional code, then assert the calculated entries saved in some of the DB's tables. Also, you can achieve the same thing using a web service. I think you get the point- there are multiple solutions to the problem. In order to be able to understand fully the explanations below, I assume that you have read about the Strategy Design Pattern. If you haven't, I suggest you to do so. I think that one of the best solutions for the previously stated problem is to use the strategy design pattern.

The context holds a dependency to IStrategy and wraps the calls to the concrete strategies. In our case, the purchasing workflow is placed in the PurchaseContext class. We call the PurchaseItem method to perform a purchase. The PurchaseContext has a dependency to IPurchasePromotionalCodeStrategy. So depending on what we want to test we can use the UI to apply and assert the promotional codes or use a direct DB access for a faster tests' execution. IPurchasePromotionalCodeStrategy Interface

The interface contains only three methods. One that applies the code, one to assert the code and the last one to get the discount's amount. PurchaseContext Implementation without Null Object Design Pattern This is how looks the PurchaseContext code if we don't use the Null Object Design Pattern.

As I already have mentioned in the body of the PurchaseItem method you can find the order's completion workflow. Though a constructor injection, we pass all dependencies of the PurchaseContext such as all required pages and the concrete implementation of the IPurchasePromotionalCodeStrategy. However, there might be cases where we don't need to apply promotional codes and the strategy might no be initialized because of that we use null checks. If we don't use them a NullReferenceException might be thrown.

UI Implementation of IPurchasePromotionalCodeStrategy This is how the UI implementation of the IPurchasePromotionalCodeStrategy interface looks.

This concrete implementation of IPurchasePromotionalCodeStrategy is dependent to the PlaceOrderPage. We use the UI to apply and assert the promotional codes. Null Object Implementation of IPurchasePromotionalCodeStrategy The default implementation of the promotional codes' interface is pretty simple.

We return zero for the discount amount and the body of the rest of the methods is empty. PurchaseContext Implementation with Null Object Design Pattern

As you have most probably noticed the code is almost identical to the previous implementation with the small difference that the null checks are missing. Null Object Design Pattern is about giving a default implementation for filling the absence of an object and it is not about avoiding null reference exceptions. If you see Null Object Design Pattern implemented with no object collaboration then there is something wrong in the way the pattern is implemented.

Null Object Design Pattern in Tests