A year or so ago I wrote a series of blog posts about building testable modules using the Model-View-Presenter (MVP) pattern.  The MVP pattern of development provides many of the benefits attributed to the Model-View-Controller (MVC) pattern, which has become very popular recently as an alternative approach to ASP.NET development. 

You can have your cake and eat it too.

Its main strength though is that it retains most of the benefits of the WebForms Framework of rich controls, with which we are familiar. 

The MVP pattern achieves this by requiring the View (usually a UserControl or Page)which receives control from the WebForms Framework to pass “control” to a Presenter class, and it requires a good deal of discipline from developers to ensure that the pattern is followed. 

The pattern also requires developers to “wire-up” the three classes View, Presenter and Model (or ViewModel) every time they need a new control (or View).

This degree of complexity has tended to hamper the use of the MVP pattern, as it requires much more work on the part of developers in general (and module developers in particular).

I am pleased to announce that in the next public release of DNN (version 5.3) we will be including a set of base classes that provide most of this wiring-up out-of-the-box. 

This new framework is based on a fairly new Codeplex project WebFormsMVP from Tatham Oddie (of Readify in Australia) and Damian Edwards (formerly of Readify, but now assimilated by the Borg (Microsoft)).  Many of you will know that Phillip Beadle a long-time DNN Community member and now DNNCorp Employee also used to work at Readify.

We had already decided to add MVP support for module development in this development cycle and after meeting with Damian and Tatham at the recent MVP (as in Microsoft Most Valuable Professional) summit in Redmond, we decided to replace our MVP (Model-View-Presenter) code with their Library, which was much more advanced, and was licensed under a compatible Open Source license.  Tatham and Damian have used the WebFormsMVP framework on a number of high-profile websites in Australia so it is well-tested

Move over PortalModuleBase – Hello ModulePresenter and ModuleView<Model>

In order to take as much advantage as we can from this new framework we have built a thin layer on top of their code to ensure that the Presenters and Views all know about Module Context and Portal Settings. 

Two new modules that we will be delivering as part of the 5.3 release have been built on this new framework and will showcase how to use the framework and how to write tests at every layer of the application.

In addition, I will blog in future article(s) on how you can use this new framework to create testable modules of your own.

In an earlier article in this blog series I described the life of Robert Nurse.  He married Ann Jane Taylor at St. Michael, Two Mile Hill on 30^th May 1854, two months after his father Robert Nurse died. [1]

Ann Jane Taylor, Robert Nurse’s wife, was a descendent of John Taylor, the Landscape Painter. He was my 5th great grandfather.

In the previous article in this series I described the life of John Taylor.  I now turn to his son Henry Taylor (my 4th great grandfather).  Henry was born in 1775, being baptized on 7th October 1775 at St. Swithen’s, Walcot in Bath [2].

Very little is known about Henry Taylor. He apparently moved quite frequently, eventually settling down in the village of Winsley, just outside Bradford-upon-Avon in Wiltshire. This comes from my grandfather's notes as he records the birthplaces of the children, which have been confirmed from the parish registers of the parishes concerned.

Richard, the eldest was born at Winterbourne [3], near Salisbury, Wiltshire. Winterbourne was also the place of Henry’s marriage in 1798 to Jane Watts[4].

The next two children, Francis Fane and Charles were born at Farley[5], to the east of Salisbury, near the Hampshire border. Harriet was born in Burleigh, Hampshire, Charlotte and Eliza were born in Buttermere [6], Wiltshire and the last child, Thomas was born at Barefield, near Bradford-upon-Avon and was baptized at St Nicholas, Winsley on 19 March 1815. [7]

According to the parish register of Winsley, Henry Taylor was a farmer.

Figure 1 The Family of Henry and Jane Taylor.

While I have confirmed most of the factual data in my grandfather’s notes, the link between Ann Jane Taylor and John Taylor, the Landscape Painter has not been proven. It is however strongly suggested by the name of Ann Jane Taylor's father, Henry's second son. His full name was Francis Fane Taylor. Francis Fane, as mentioned briefly in my previous article on Henry’s father was the younger son of Henry and Charlotte Fane (nee Luther), Rebecca Taylor's sister.

Francis Fane and Henry Taylor would have been cousins.

According to Burke, although Francis Fane was MP for Dorchester, the county town of Dorset, he had a residence at Green Park Place in Bath, as did Richard Taylor, Henry's brother. While it is unusual to name one's son after one's cousin, it would be even more unusual to name one's son after a stranger, no matter how important that person might be.

It thus appears that Henry Taylor (Francis Fanes Taylor’s father and Ann Jane Taylor’s grandfather) is the same Henry Taylor mentioned in the will of Rebecca Taylor (nee Luther), and thus Ann Jane Taylor is the great-grand daughter of John Taylor, the Landscape Painter.

Bibliography and Notes

[1] I have a copy of the Marriage Certificate for Robert and Ann.

[2] www.freereg.com

[3] Parish Register of Winterbourne Gunner, 1574-1932, Wiltshire Record Odffice.

[4] Parish Register of St Michael and All Angels, Winterbourne Earls, 1557-1932, Wiltshire Record Office.

[5] Parish Register of All Saints, Farley, 1661-1867, Wiltshire Record Office

[6] Parish Registers of St. James, Buttermere, 1720-1812, Wiltshire Record Office.

[7] Parish Register of St. Nicholas, Winsley, 1724 – 1843, Society of Genealogists Copy.

One of the tenets of Unit Testing is that in order to test a piece of code we often need to create some alternate implementation of one or more of the Interfaces involved in a test.  This concept is generally called a Test Double.  However there are many types of Test Double, and there is some degree of confusion about the types of doubles used.

In this installment of “Adventures in Testing” I will attempt to clarify the types of Test Doubles.

Dummies

Dummies are the simplest type of test double – these are objects that are needed to be passed around but they don’t actually do anything so they can have a very simple implementation.  Usually they are required just to fill a parameter list in a method call.

An example would be a test for the following constructor -

   1:  Public Sub New(ByVal createView As ICreateVocabularyView, _

   2:                 ByVal vocabularyController As IVocabularyController, _

   3:                 ByVal scopeTypeController As IScopeTypeController)

   4:      MyBase.New(createView)

   5:      Arg.NotNull("vocabularyController", vocabularyController)

   6:      Arg.NotNull("scopeTypeController", scopeTypeController)

   7:   

   8:      '.....

   9:  End Sub

In this example the constructor takes three parameters.  If we are testing that the constructor throws an Exception if one of the arguments are null, we need to ensure that the other parameters are not null.  So for example our test to ensure that the Constructor throws an Exception if the VocabularyController is null might look like this.

   1:  public void Constructor_Requires_Non_Null_VocabularyController()

   2:  {

   3:      //Arrange

   4:      DummyCreateVocabularyView view = new DummyCreateVocabularyView();

   5:      DummyScopeTypeController scopeTypeController = new DummyScopeTypeController();

   6:   

   7:      //Act

   8:      CreateVocabularyPresenter presenter = new CreateVocabularyPresenter(view, 

   9:                                                      null, 

  10:                                                      scopeTypeController);

  11:      

  12:      //.....

  13:  }

We don’t care about the implementation of the first (ICreateVocabularyView) or third (IScopeTypeController) interfaces in this test, we just need them to be non-null – all we care about is that the constructor throws if the second parameter is null.

Fakes

The other three types of Test Doubles all have some form of implementation as we are testing some part of the Interface in question.

Fake objects usually have full working implementations, but they use some shortcut, and are not of production quality.  An example of a Fake object would be when testing the business layer of an application, where we create an in-memory Fake DataService class to simulate the data access, and allow us to test the business layer methods, without requiring a database to be set up.

Stubs

Stubs provide canned answers to calls made during a test, and usually don’t respond at all to anything outside what's programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it 'sent', or maybe only how many messages it 'sent'.

Mocks

Mocks are usually dynamically created by a mocking framework – (in DotNetNuke we use Moq as the mocking framework). Mock objects are preprogrammed with expectations which form a specification of the calls they are expected to receive (see Figure 3)

   1:  public void VocabularyListPresenter_On_Add_Redirects_To_CreateVocabulary()

   2:  {

   3:      // Arrange

   4:      Mock<IVocabularyController> mockController = new Mock<IVocabularyController>();

   5:      Mock<IVocabularyListView> view = new Mock<IVocabularyListView>();

   6:      view.Setup(v => v.Model).Returns(new VocabularyListModel());

   7:   

   8:      Mock<HttpContextBase> httpContext = new Mock<HttpContextBase>();

   9:      Mock<HttpResponseBase> httpResponse = new Mock<HttpResponseBase>();

  10:      httpContext.Setup(h => h.Response).Returns(httpResponse.Object);

  11:   

  12:      VocabularyListPresenter presenter = new VocabularyListPresenter(view.Object, 

  13:                                                      mockController.Object)

  14:      {

  15:          HttpContext = httpContext.Object,

  16:          ModuleId = Constants.MODULE_ValidId,

  17:          TabId = Constants.TAB_ValidId

  18:      };

  19:   

  20:      // Act (Raise the AddVocabulary Event)

  21:      view.Raise(v => v.AddVocabulary += null, EventArgs.Empty);

  22:   

  23:      // Assert

  24:      httpResponse.Verify(r => r.Redirect(Globals.NavigateURL(Constants.TAB_ValidId,

  25:                                          "CreateVocabulary",

  26:                                          String.Format("mid={0}", Constants.MODULE_ValidId))));

  27:  }

In Figure 3 we are using 4 separate Mock objects, but lets focus on the two mocks created in lines 8 and 9.  In line 8 we create a Mock HttpContextBase using Moq’s Mock class, and in line 9 we create a Mock HttpResponseBase.  Just creating the Mock does nothing more that create in memory an object that can respond to an interface, or (as in this case) an abstract base class.

In line 10 we setup the Mock HttpContextBase, so that when it receives a call to its Response property it will return the object represented by the Mock HttpResponse object.

In line 15 we set HttpContext property of the presenter to this Mock HttpContextBase.

Now we have set up our test so we can test the view’s AdddVocabulary method (see Figure 4), which is designed to redirect to a new page when the AddVocabulary button is clicked.

   1:  Public Sub AddVocabulary(ByVal sender As Object, ByVal e As EventArgs)

   2:      Response.Redirect(NavigateURL(TabId, _

   3:                                    "CreateVocabulary", _

   4:                                    String.Format("mid={0}", ModuleId)))

   5:  End Sub

So, in line 21 we raise the AddVocabulary event by calling the Raise method of the Mock view.  This will cause the presenter’s event handler to be triggered and in line 24 we verify that this caused our Mock Response object to have its Redirect method called, with the expected url.

Note: This example is based on the new Model-View-Presenter code which will be included in DotNetNuke 5.3 and provides a new Module Development Framework that provides full testability.

One of the advantages of a Mocking Framework like Moq is that it can be used to replace most types of Test Double.  For example we can write the test using Dummy objects in Figure 2 to use Mocks (Figure 5).

   1:  public void Constructor_Requires_Non_Null_VocabularyController()

   2:  {

   3:      //Arrange

   4:      Mock<ICreateVocabularyView> view = new Mock<ICreateVocabularyView>();

   5:      Mock<IScopeTypeController> scopeTypeController = new Mock<IScopeTypeController>();

   6:   

   7:      //Act, Assert

   8:      CreateVocabularyPresenter presenter = new CreateVocabularyPresenter(view.Object, 

   9:                                                          v, 

  10:                                                          scopeTypeController.Object);

  11:   

  12:      //..

  13:  }