–Howard Thurman

Conditions are never just right.  People who delay action until all factors are favorable do nothing.”
– William Feather

Our best friends and our worst enemies are our thoughts.  A thought can do us more good than a doctor or a banker or a faithful friend.  It can also do us more harm than a brick.

–Frank Crane

How true this is!  How many times have I been prevented from doing something simply because of a doubtful or fearful thought?  How powerful and empowering are ‘true’ and ‘right’ thoughts about our self and others!

Men spend their lives in anticipation, in determining to be vastly happy at some period when they have time.  But the present time has one advantage over every other — it is our own.  Past opportunities are gone, future have not come.

–Charles C. Colton

If we all worked on the assumption that what is accepted as true really was true, there would be little hope of advance.

–Orville Wright

How different would all our lives be if Mr. Wright hadn’t challenged assumptions about the possibility of flight?

Here are a list of the parameters available in the PropertyBag along with the names of the files you should create.  I’m using NVelocity, so my views end with the .VM extension.

List View

View Name: List.vm
$Items : a listing of all the records for the given model

New View

This is the view that collects information for a new record.  The form action should point to the Create controller action.

View Name: new{classname}.vm  (e.g.: if you have a model called Study, your view name will be newStudy.vm)
${classname} : is the item that you’re editing.

When creating for elements, you should name them with the format name=”classname.propertyname” (e.g.: for the Study model, if I have a property called Name, then I should add a form element with the name “Study.Name”.

Create View

There is none… this controller action just redirects to the list view after the new record is created.

Edit View

View Name: edit.vm
Query String:
id : the primary key of the record (I’m not sure what happens with models using composite keys)
The form elements have the same name format as the Create view, which is name=”classname.propertyname”.

[I'm still working to gather information on the child collection properties and the available options for those collections]

Confirm View

This is the delete confirmation view.  I usually use the JavaScript ‘confirm’ method and the do a redirect to the delete action.

View Name: confirm.vm
$classname : the record to delete
QueryString:
id: the primary key of the record to delete.

Remove View

There is no view for this action.  The controller just redirects to the list view.

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.

Person Class

Person Mother Class

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.

BaseMother Generic Class

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.

PersonMother Class with Method Chaining. The Create method is static here.

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).

ARBaseMother Class with Method Chaining

I have a few other methods on the ARBaseMother to help with my ActiveRecord testing.

Person Mother AR Class with Method Chaining

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.