Over the past few months, I have been designing a system which integrates with a number of database servers (7 within a single application) across several different schema types (3 in a single application). I have also started to see the value in writing good unit tests as connecting to a live database usually cannot give you the correct data for a good test.
The Object Mother Design Pattern
I have found that using the Object Mother design pattern to create the model objects that I use inside a test has decrease the number of lines I have to write for a realistic unit test. Essentially, the object mother is a class with several static functions used to create object. Using this class to create your objects means that the code inside you unit test function can focus on the actual testing. Martin Fowler has a good overview of the Object Mother Design Pattern and Peter Schuh and Stephanie Punke have also written a nice paper on the pattern as well.
You can then use the PersonMother class like so:
Person newPerson = PersonMother.Create();newPerson.FirstName = "John";newPerson.LastName = "Doe";newPerson.Save();
This is all fine and good, but what if you need to customize your object once you’re object mother has returned the object to you? Maybe we want to automatically set the person’s name to “John Doe” in our create method, but what if we want to add some children? What if in some cases, we don’t want to have the returned Person object to have any Children in the collection. Then you’re back to having a complex unit test again where more lines (and screen real estate) is dedicated to the object rather than the test.
Note that if your domain model is such that a few more static methods on the Mother class will do, then you’re probably fine with the basic ObjectMother pattern. However, if your domain model is complex and you need to test any number of model permutations very easily, then method chaining may help.
Enter the Object Mother with Method Chaining
The concept here is to create a single method in the Object Mother called Create() which takes no parameters and returns a valid instance of the Object Mother Class. This means that if the object is persisted to the database right after the object mother returns, the database shouldn’t throw any validation errors.
The concrete Object Mother class then has a series of methods which return an instance of the Object Mother.
In this way, methods can be executed in a chained manner, reducing the number of lines used to create and customize the object. An added benefit is that dependent objects can be assembled by another Object Mother class and the passed into a method on the parent object’s mother class.
Using .Net generics, we can create a base Object Mother class which can make the implementation of concrete Object Mother Classes much easier.
Person newPerson = PersonMother.Create() .SetName("John") .AddChild(PersonMother.Create().SetName("Johnny").Value)) .Value;newPerson.Save();
Note that all that code can be on one line. I’ve just expanded it to make it easier to read in this format.
In my most recent project, I have been using ActiveRecord as my ORM. I created a subclassed ObjectMother class, allowing me to perform database operations as part of the method chain. This is especially useful when object persistence has to occur is a certain order (of courses, defining a proper cascade within the BelongsTo attribute can also help with this… this is just an example).
I have a few other methods on the ARBaseMother to help with my ActiveRecord testing.
Now, the example again:
Person newPerson = PersonMother.Create() .SetName("John") .AddChild(PersonMother.Create().SetName("Johnny").Save().Value) .Save() .Value;newPerson.Save();
I have found that this pattern makes writing unit tests much easier… which means that I might actually write more of them!
Do you have an pattern which help you write tests? Please share them in the comments below.





