This is the second article dedicated to the Null Object Design Pattern part of the Design Patterns in Automated Testing series. In the last post, I showed you how you can add a default behavior to your strategies. However, the usage of the strategies' context was tedious because its constructor accepted many dependencies that needed to be initialized manually. Here I will show you, how you can improve the usage of the Null Object Design Pattern through the Singleton Design Pattern and Unity IoC container.

Immutable Strategies via Base Singleton Implementation If you have not already read my previous article about the Null Object Design Pattern, I suggest you to do so. The problem that I am going to solve here is the tedious initialization of the strategies' context. Another thing that can be improved is the performance. It makes sense to create just a single immutable instance of the NULL class. Because the NULL class just has default behavior, it makes more sense to cache it. One way to do it is to create a base class that contains inside of it the Null object.

All strategies derive from this base class.

The difference with the previous implementation is that we do not have a separate file with the NullPurchasePromotionalCodeStrategy. The NULL property can be accessed by every child of the BasePromotionalCodeStrategy class. Below you can find how one sample test will look.

This is a convenient approach if you use the NULL object in more than one test because its instance will be reused among them.

Improve Null Object Design Pattern through Pure Singleton Design Pattern Implementation In my opinion nested classes or files containing more that one class is not a best practice. Because of that, I like more the pure implementation of the Singleton Design Pattern. Since most of the strategies need different parameters for every test, it doesn't make sense to be implemented as singletons. For the given examples I think this is appropriate only for the NULL object. For this implementation we don't need the base class anymore, the singleton's code can be placed only in the NullPurchasePromotionalCodeStrategy class.

The usage in tests is identical to the previous approach, but the code is cleaner.

Improve Null Object Design Pattern Further through Unity IoC Container As you can see from the last example, the initialization of the PurchaseContext is a real pain. If you have read my article about Unity IoC Container- Use IoC Container to Create Page Object Pattern on Steroids, you most probably have figured out what I meant with the title of this section. We can use almost all of the dependency objects as singletons since they don't have any state. Also, Unity can resolve all of them for us- recursively. The first thing you need to do is to register all required types in the container.

When you pass an instance of ContainerControlledLifetimeManager to the RegisterType method, you configure Unity to resolve your type as a singleton. All pages have only a single implementation and no interface because of that we register them directly. This is not valid for the promotional code's strategies. Therefore, we tell Unity to resolve the IPurchasePromotionalCodeStrategy as our Null Object Design Pattern implementation by default. Through the last line of the method, we register the already created instance of WebDriver. Most of this code can be moved to the AssemblyInitialize method of our test project. Resolve Null Object through Unity IoC Container

As you can see the code of the test is shorter and more readable thanks to the Unity container. Moreover, all pages and all other dependencies will be reused in the rest of the tests.

Resolve Non-Null Object through Unity IoC Container

You can override the default strategy implementation for the promotional codes.