David,

I think the problem is more with your unit test than the framework per se.  Use a static stub or a recording stub for all or most of IHttpContext and most of that code in the unit test goes away.

MVC should allow you to move much more of the Controller to View code into easier state based testing.  Stub all the IHttpContext stuff instead of mocking it.  Just load up the incoming data, pass it into the Controller, and check the state of the "Model" afterwards.  My vote is that state based testing is usually easier than interaction based testing.

 RouteData routeData = new RouteData();

 routeData.Values.Add("Action", "About");

 routeData.Values.Add("Controller", "Home");

This code is just flat out ugly.  Again though, it's as much an issue with the unit test as the ugly API.  I'd create an ObjectMother or something similar for constructing RouteData in a single line of code in the test.  I got blistered in my blog last month for suggesting that C# 4 should get a one line syntax for creating hash tables ala Ruby.  I'm feeling very justified about that request after looking at that ugliness above that's gonna get created over and over again.

I still think the linear MVC approach has more to offer in terms of testability in the end than MVP with WebForms ever can.   You can beat the Route handling testability with some better test harness helpers to eliminate the tediousness of setting up the HttpContext stuff.  If you make the inevitable comparison to Ruby on Rails, you'll see that RoR has a lot of Rails specific extensions to the Ruby xUnit equivalent and RSpec to make Rails testing easier for exactly the kind of scenarios that you described.  The MVC framework just needs some of the same.

Your example of MVP testing with WebForms isn't complex enough to bring out the pain of MVP with WebForms.  That sample worked perfectly because it was "linear."  The screen lifetime was easily predictable.  As soon as you throw screen behavior happening from different points in the page lifecycle from subsequent Postback's I think the MVP abstraction leaks badly in ASP.NET.  In the MVC lifecycle the lifecycle is *always* linear and predictable in its flow compared to the WebForms event lifecycle.

Pingback from  dan » Model-View-Presenter Seems Easier to Test Than ASP.NET MVC

@David,

I concur with David, and I'll share my code:  palermo.googlecode.com/.../trunk

Here is an excerpt from one of my controller unit tests in ProductControllerTester.  Notice there is less setup than yours and there is no need to even mess with a route.  

[Test]

       public void ShouldListProductsInStock()

       {

           MockRepository mocks = new MockRepository();

           IProductListingService service =

               mocks.CreateMock<IProductListingService>();

           ProductListingItem[] productListingItems = new ProductListingItem[]

               {

                   new ProductListingItem(new Product()),

                   new ProductListingItem(new Product()),

                   new ProductListingItem(new Product())

               };

           SetupResult.For(service.GetProductsInStock()).Return(

               productListingItems);

           mocks.ReplayAll();

           //running code

           TestProductController controller =

               new TestProductController(service, null);

           controller.ListInStock();

           //finished running code.

           Assert.That(controller.ActualViewData,

                       Is.EquivalentTo(productListingItems));

           Assert.That(controller.ActualViewName, Is.EqualTo("List"));

           Assert.That(controller.ActualActionRedirected, Is.Null);

       }

public class TestProductController : ProductController

       {

           public string ActualActionRedirected;

           public object ActualViewData;

           public string ActualMasterName;

           public string ActualViewName;

           public TestProductController(IProductListingService service,

                                        IProductRepository repository)

               : base(service, repository)

           {

           }

           protected override void RenderView(string viewName,

                                              string masterName,

                                              object viewData)

           {

               ActualViewName = viewName;

               ActualMasterName = masterName;

               ActualViewData = viewData;

           }

        protected override void RedirectToAction(object values)

        {

// ActualActionRedirected = values.ToString();

        }

       }

       public class FakeView : IView

       {

           public void RenderView(ViewContext viewContext)

        {

        }

       }

Jeremy, in regard to your sample code, is that test controller going to be the same for all controllers sufficiently that I could create a test base controller and inherit from those and make it implement the interfaces of all the different controllers? Otherwise I see it still as too much work, having to create stubs for everything to test it. That's what the beauty of Rhinomock was all about.

Hey David,

You really compared apples to oranges with your two examples.  I would like to see you unit test a redirect with your MVP framework.

Here would be an equivalent MVC unit test of your linear MVP unit test.

[Test]

public void EmptyCustomerNameShouldCauseInvalidCustomerMessage()

{  

   CustomerController controller = new CustomerController();

   controller.Add(string.Empty, "Jester", "555-1212");

   Assert.IsTrue(controller.ViewData.Containers("message"));

   Assert.AreEqual("Invalid Customer...", controller.ViewData["message"]);

}

Which one was simpler again?

   Expect.Call(mockView.CustomerName).Return(string.Empty);

   Expect.Call(mockView.CustomerTitle).Return("Jester");

   Expect.Call(mockView.PhoneNumber).Return("555-1212");

   mockView.Message = "Invalid Customer...";

   mocks.ReplayAll();

   presenter.onAddCustomer();

   mocks.VerifyAll();

}

ASP.Net MVC is Easier to Test than Model-View-Presenter

Hey David,

Your comment to Jeremy:  "I realize my other unit test with MVP is trivial, but sometimes you have simple linear tests and I would hate that doing these tests with MVC would be so much more complicated."

You make it sound like doing simple linear tests with MVC is much more complicated than with MVP.  That is the statement I refute with my comment and post.

It would also be helpful to your readers if you would write a unit test for doing a redirect in MVP.  I feel you are very misleading when you say MVC looks like a lot of work to test and you do not provide an equivalent, simpler, test in MVP.

I mentioned in my earlier post: Model-View-Presenter Seems Easier to Test Than ASP.NET MVC that my experience

Hey David,

I didn't mean to come off so negative.  I know you have a large readership and didn't want them to get the wrong, possibly first, impression of MVC.  As I cook-up some real world scenarios, I'll make sure and pass them along.

-Bill

@Bill,

Since you have some more experience, can you answer the question I posed to Jeremy?

Thanks

Today was another public holiday. It was boring and I tried to hack NAnt to build with multiple threads

Pingback from  rascunho  &raquo; Blog Archive   &raquo; links for 2007-12-17

@Joe,

Your question is Mocking vs. Stubbing?  I think that is a personal preference and both have their uses.  I like to Stub domain objects for use in multiple test fixtures but I will generally mock service dependencies.

@Bill,

No, it's not really whether to mock or stub (although I personally prefer mocking). It's about whether I have to create a Test controller for EACH controller and whether the code is generic. I just find it too much work to do each time.