Introduction
In my series of articles “Design Patterns in Automation Testing“, I am presenting you the most useful techniques for structuring the code of the automation tests. Today’s publication is about the Singleton Design Pattern. In my previous posts, I have explained how to use the Page Object and Facade Design Patterns. If you are not familiar with them, I advise you to read my articles on the matter. The Singleton Design Pattern can be used in the automation tests to build up easier access to page objects and facades. Its usage can speed up the tests writing process dramatically. In this article, I am going to show you the best and most straightforward approaches to integrating the Singleton Design Pattern in your test automation framework.
Definition
Ensure a class has only one instance and provide a global point of access to it.
- Instance control – prevents other objects from instantiating their copies of the Singleton object, ensuring that all objects access the single instance.
- Flexibility – since the class controls the instantiation process, the class has the flexibility to change the instantiation process.
- Lazy initialization – defers the object’s creation until it is first used.
UML Class Diagram
Participants
The classes and objects participating in this pattern are:
- Page Objects (
BingMainPage)- Holds the actions that can be performed on the page like Search and Navigate. Exposes an easy access to the Page Validator through the Validate() method. The best implementations of the pattern hide the usage of the Element Map, wrapping it through all action methods. BasePage<S, M> – Gives access to the child’s page element map class and defines a standard navigation operation.BasePage<S, M, V> – Adds an instance to the child page’s validator class through the Validate method.BaseSingleton – This is an abstract class that contains a static property of its child instance
Singleton Design Pattern C# Code
Create Singleton in BasePage
The most straightforward way to integrate the Singleton Design Pattern in all of your existing page objects is to add a static variable and property in the BasePage class. If you are not familiar what the BasePage classes are, refer to my article- Advanced Page Object Pattern in Automation Testing.
public class BasePage<M>
where M : BasePageElementMap, new()
{
private static BasePage<M> instance;
protected readonly string url;
public BasePage(string url)
{
this.url = url;
}
public BasePage()
{
this.url = null;
}
public static BasePage<M> Instance
{
get
{
if (instance == null)
{
instance = new BasePage<M>();
}
return instance;
}
}
protected M Map
{
get
{
return new M();
}
}
public virtual void Navigate(string part = "")
{
Driver.Browser.Navigate().GoToUrl(string.Concat(url, part));
}
}
The drawback of the above solution is that you cannot reuse the singleton implementation for your Facade classes. The answer to the mentioned problem is to create a base generic singleton class that can be derived from all pages and facades.
Non-thread-safe BaseSingleton Class
Find below, the most trivial implementation of the generic base class for the Singleton Design Pattern.
public abstract class Nonthread-safeBaseSingleton<T>
where T: new()
{
private static T instance;
public static T Instance
{
get
{
if (instance == null)
{
instance = new T();
}
return instance;
}
}
}
In most scenarios for automation tests, this solution should be sufficient. However, this implementation is not thread-safe. To be possible to execute tests in parallel, I am going to propose you other variations of the base class that are thread-safe.
Thread-safe BaseSingleton Class with Lock
public abstract class Thread-safeBaseSingleton<T>
where T : new()
{
private static T instance;
private static readonly object lockObject = new object();
private thread-safeBaseSingleton()
{
}
public static T Instance
{
get
{
if (instance == null)
{
lock (lockObject)
{
if (instance == null)
{
instance = new T();
}
}
}
return instance;
}
}
}
Here, I am using a lock statement that ensures that one thread does not enter a critical section of code while another thread is in the critical section. If another thread tries to enter a locked code, it will wait, block until the object is released. As you can see, the code doesn’t lock the T instance. Instead, it locks its internal object. It is done to prevent deadlocks.
Thread-safe BaseSingleton Class with Lazy
The built-in .NET framework generic class Lazy<T> saves some code for implementing the lazy initialization. Also, it is thread-safe.
public abstract class ThreadSafeLazyBaseSingleton<T>
where T : new()
{
private static readonly Lazy<T> lazy = new Lazy<T>(() => new T());
public static T Instance
{
get
{
return lazy.Value;
}
}
}
Thread-safe BaseSingleton Class with Nested Classes
The most complicated variation of the base class implementing Singleton Design Pattern uses nested classes and reflection.
public abstract class ThreadSafeNestedContructorsBaseSingleton<T>
{
public static T Instance
{
get
{
return SingletonFactory.Instance;
}
}
internal static class SingletonFactory
{
internal static T Instance;
static SingletonFactory()
{
CreateInstance(typeof(T));
}
public static T CreateInstance(Type type)
{
ConstructorInfo[] ctorsPublic = type.GetConstructors(BindingFlags.Instance | BindingFlags.Public);
if (ctorsPublic.Length > 0)
{
throw new Exception(string.Concat(type.FullName,
" has one or more public constructors so the property cannot be enforced."));
}
ConstructorInfo nonPublicConstructor =
type.GetConstructor(BindingFlags.Instance |
BindingFlags.NonPublic, null, new Type[0], new ParameterModifier[0]);
if (nonPublicConstructor == null)
{
throw new Exception(string.Concat(type.FullName,
" does not have a private/protected constructor so the property cannot be enforced."));
}
try
{
return Instance = (T)nonPublicConstructor.Invoke(new object[0]);
}
catch (Exception e)
{
throw new Exception(
string.Concat("The Singleton could not be constructed.
Check if ", type.FullName, " has a default constructor."), e);
}
}
}
}
The nested class contains static constructor to tell the C# compiler not to mark the type as before-field-init. Now the BasePage classes should not have constructors to follow the Singleton Design Pattern, because of that the new() class constraint is removed.
The structure of the base classes for the Page Object Pattern should be slightly changed due to the earlier mentioned reason.
public abstract class BasePageSingletonDerived<S, M> : thread-safeNestedContructorsBaseSingleton<S>
where M : BasePageElementMap, new()
where S : BasePageSingletonDerived<S, M>
{
protected M Map
{
get
{
return new M();
}
}
public virtual void Navigate(string url = "")
{
Driver.Browser.Navigate().GoToUrl(string.Concat(url));
}
}
public abstract class BasePageSingletonDerived<S, M, V> : BasePageSingletonDerived<S, M>
where M : BasePageElementMap, new()
where V : BasePageValidator<M>, new()
where S : BasePageSingletonDerived<S, M, V>
{
public V Validate()
{
return new V();
}
}
One of the significant changes in the code is the new S generic parameter that represents the type of the child page which is going to be initialized. Also, you can notice the absence of constructors and that the both classes are marked as abstract.
The page object class that derives from these classes can look like the following:
public class BingMainPage : BasePageSingletonDerived<BingMainPage,
BingMainPageElementMap, BingMainPageValidator>
{
private BingMainPage() { }
public void Search(string textToType)
{
this.Map.SearchBox.Clear();
this.Map.SearchBox.SendKeys(textToType);
this.Map.GoButton.Click();
}
public override void Navigate(string url = "<a href="http:
{
base.Navigate(url);
}
}
I want to emphasize that the constructor of this class is marked as private, which prevents the creation of a default constructor.
Tests Using Singleton Design Pattern
Now you can use the page objects directly in your code without the keyword new, thanks to the singleton design pattern.
[TestClass]
public class AdvancedBingSingletonTests
{
[TestInitialize]
public void SetupTest()
{
Driver.StartBrowser();
}
[TestCleanup]
public void TeardownTest()
{
Driver.StopBrowser();
}
[TestMethod]
public void SearchTextInBing_Advanced_PageObjectPattern_NoSingleton()
{
P.BingMainPage bingMainPage = new P.BingMainPage();
bingMainPage.Navigate();
bingMainPage.Search("Automate The Planet");
bingMainPage.Validate().ResultsCount(",000 RESULTS");
}
[TestMethod]
public void SearchTextInBing_Advanced_PageObjectPattern_Singleton()
{
S.BingMainPage.Instance.Navigate();
S.BingMainPage.Instance.Search("Automate The Planet");
S.BingMainPage.Instance.Validate().ResultsCount(",000 RESULTS");
}
}
So Far in the "Design Patterns in Automated Testing" Series
- Page Object Pattern
- Advanced Page Object Pattern
- Facade Design Pattern
- Singleton Design Pattern
- Fluent Page Object Pattern
- IoC Container and Page Objects
- Strategy Design Pattern
- Advanced Strategy Design Pattern
- Observer Design Pattern
- Observer Design Pattern via Events and Delegates
- Observer Design Pattern via IObservable and IObserver
- Decorator Design Pattern- Mixing Strategies
- Page Objects That Make Code More Maintainable
- Improved Facade Design Pattern in Automation Testing v.2.0
- Rules Design Pattern
- Specification Design Pattern
- Advanced Specification Design Pattern
If you enjoy my publications, feel free to SUBSCRIBE
Also, hit these share buttons. Thank you!
Source Code
References
The post- Singleton Design Pattern in Automation Testing appeared first on Automate The Planet.
All images are purchased from DepositPhotos.com and cannot be downloaded and used for free.
License Agreement
