Ben,

I've used the MVP paradigm on a couple of WinForms clients with very good results. You're absolutely right that you can't get away with only testing the presenters with mocks or stubs, but it makes the UI control logic vastly easier to unit test before you even try the integrated stack. You've always got to write multiple types and layers of tests, but unit testing the presenter logic will remove a lot of bugs quickly before you even attempt to debug through the full stack.

Even without using something like NUnitForms on the views you'll get fewer bugs there because they're thinner and much simpler. The "view" code itself is also easier to test because it doesn't have quite so much coupling to the layers underneath it.

I like to start with just a mockup, code the presenter and flesh out the ISomethingView interface, then build the view last. I've routinely seen new screen features work on the very first try when you work this way.

Here's another WinForms specific example of MVP --> http://codebetter.com/blogs/jeremy.miller/articles/129546.aspx

Incest comes to mind. I think I met Jeffrey for the first time right after his post.

Here's another good search to run:

http://www.google.com/search?hl=en&lr=&q=%22model+view+presenter%22+site%3Acodebetter.com

Hi,

MVP is a great pattern to test the UI logic and to make the separation of concerns when it comes to UI logic. I have used it very succesfully lately, on winforms, asp.net and even with net cf apps.

However, from time to time I do get the feeling of insecurity about the UI itself, as MVP is a pattern that makes testing the presenter/controller very easy, but the UI can remain completely untested.

For this reason I am thinking about ways to extend automated testing also to the UI. I believe that testing also the View is important for windows.forms apps as they are much more complex then web app views. If you also want to benefit from databinding (and sometimes you're compelled to do it by some third party controls) then testing the view becomes more and more important.

So what do we do about this? One idea I had was to extend the view itself and make the mock. For instance, normally we could have:

public interface IView
{
void SetOrder(Order o);
Order GetOrder();
void DisplayMessage(string message);
}

public class Presenter
{
...
public void Init()
{
this.view.SetOrder(model.Order);
}
...
public void Save()
{
try
{
orderBusiness.Save(view.GetOrder());
view.DisplayMessage("Order saved ok.");
}
catch{
view.DisplayMessage("Order could not be saved.");
}
}
}

public class MockView:IView
{
private Order order = null;
private ArrayList messages = new ArrayList();

...

public void SetOrder(Order o)
{
this.order = order;
}
public Order GetOrder()
{
return this.order;
}
public void DisplayMessage(string message)
{
Console.WriteLine(message);
messages.Add(message);
}
}

Very easy to test. But if in the view I use databinding that means that the view needs to become visible.

public class OrderForm:Form,IView
{
...

public void SetOrder(Order o)
{
this.SuspendBindings();
this.RemoveBindings();
this.order = o;
this.DataBind();
this.ResumeBindings();
}
public Order GetOrder()
{
this.EndCurrentEdit();
return this.order;
}
public void DisplayMessage(string message)
{
MessageBox.Show(message,...);
}
...

private void DataBind()
{
this.txtNo.DataBindings.Add("Text",order,"No");
this.txtDate.DataBindings.Add("Text",order,"Date");
}

private void SuspendBindings()
{
this.BindingContext[order].SuspendBindings();
}
private void ResumeBindings()
{
this.BindingContext[order].ResumeBindings();
}

}

So could we have the MockView actually extend the OrderView itself, se that we could also have more control over testing the view also?

What do you think?

Sorry for the code, It was written on the spot;

Hi,

After doing a little research I found out it is possible to extend the form itself to test with databinding, if needed. I will be publishing the source code on my blog soon.

Thanks,
Dan Bunea
http://danbunea.blogspot.com

Source code: Download


Lately, I have noticed that the Humble Dialog Box or Model...

Source code: Download


Lately, I have noticed that the Humble Dialog Box or Model...

This might be a bit late for you to be interested but; I'm currently looking at MVP/TDD for an internal teach in. The sample I drew up worked in a similar manner to your download. However I spotted a 'bug' in my own code and you appear to have the same issue.

public bool AlbumForm::IsClassical
{
   get{ /* ... */}
   set
   {
       cbClassical.Checked = value;
       txtComposer.Enabled = value;
   }
}

this is asnippet from your production code where you actually have business logic. i.e. setting the classical checkbox state also enables the state of another control. (In my case is was the clearing of a list before populating it.)

My current thinking is that this is wrong and should be 2 properties/methods on the IAlbumView [ComposerEnabled *and* ISClassical] such that setting the current Album on the presenter should invoke both of these methods seperatly.

I've not had enough experience using MVP to 'know' if I'm right :-) so I'm still open minded about it all.

> The presenter simply tells the view that IsClassical is true/false then its up to the view to decide what actions to take because of that.

I've thought more about this (and had a re-read of the martin fowler MVP page, which I'm sure has been updated since I last looked). The presenter implements *all* of the biz logic for any UI. The view is not allowed (my understanding of MVP) to "decide" any actions.

Now if I could the the product manager to use FitNess *and* I actually thought it was worth the effort we could have FIT tables to demonstrate what should happen in various UI senarios.

If only I'd gone to the effort of re-reading the Folwer page before my earlier post I could have better stated my thinking [now not then, which would have been then too had I read it, clear :-) ].

Cheers,

adam