This project is read-only.
Model-View-Presenter pattern description | How to: Implement the Model-View-Presenter Pattern | Model-View-Presenter QuickStarts

How to: Unit Test the Presenter

When you implement the Model-View-Presenter pattern, you can test the presenter independently of the view and model real implementations. You achieve this by replacing the view and the model with mock implementations. Testing the presenter independently of the model and view implementations helps you focus on the presentation behavior and eliminates dependencies that might not be appropriate for testing environments.
If the presenter references its view implementation class, the view implementation class is required to run the presenter’s unit tests. To enable you to easily test your presenter, you define an interface for the view and replace the view implementation reference with a reference to the view interface. This means you can easily create a mock implementation of your view for your presenter’s unit tests, and those tests will not require the real view implementation. The same approach can be applied to model objects that the presenter depends on.


The typical process for unit testing a presenter includes the following tasks:
  1. Create mock implementations for the model and the view. These mock implementations must implement the model and view interfaces respectively.
  2. For each user story, identify and add members to the view and model interfaces and implement them in the mock implementations. Write a unit test using the mock objects that perform assertions on the state of the mock objects. Finally, add code to the presenter to make the test pass.
The following procedure describes how to create a mock view.

To create a mock view
  • Define a new class that implements the view's interface.
The Add Page (with presenter), Add Master Page (with presenter), and Add User Control (with presenter) recipes included in the Composite Web Client Automation automatically generate a mock view class if you have a test project for the business module on which the recipe is executed. The mock view is defined in the same file that contains the unit tests for the presenter.
  • Implement the members defined in the interface and provide additional elements to allow you test the presenter interaction with the view. For example, you can add public properties or fields to your mock view to test whether the presenter actually sets a property value in the view.
  • The following code extracted from the Model-View-Presenter QuickStart shows a mock implementation for the ContactDetailView view. Note that the mock class implements the same interface as the real view (IContactDetailView).
class MockContactDetailView : IContactDetailView
    public bool SetViewModeCalled;
    public bool SetViewModeReadOnly;
    public bool SetViewControlsVisibleMode;
    public bool SetViewControlsVisibleCalled;
    public bool LoadStatesCalled;
    public ICollection<State> LoadStatesArgumentValue;
    public ContactDetailPresenter PresenterLoaded;
    public Customer CustomerLoaded;

    public event EventHandler EditClicked;
    public event EventHandler<DataEventArgs<Customer>> SaveClicked;
    public event EventHandler DiscardChangesClicked; 
    public event EventHandler UserControlLoaded;

    public void ShowCustomer(Customer customer)
        CustomerLoaded = customer;

    public void SetViewReadOnlyMode(bool readOnly)
        SetViewModeCalled = true;
        SetViewModeReadOnly = readOnly;

    public void SetViewControlsVisible(bool visible)
        SetViewControlsVisibleCalled = true;
        SetViewControlsVisibleMode = visible;

    public void LoadStates(ICollection<State> states)
        LoadStatesCalled = true;
        LoadStatesArgumentValue = states;

    public void FireEditClicked()
        if (EditClicked != null)
            EditClicked(this, EventArgs.Empty);

    public void FireSaveClicked(Customer customer) { // ... }
    public void FireDiscardChangesClicked() { // ... }
    public void FireUserControlLoaded() { // ... }

    public ContactDetailPresenter Presenter
        get { return PresenterLoaded; }

You can use the MockContactDetailView class to test the interaction of the presenter with the view. It implements methods that the presenter calls and sets public flags that you query in your unit tests. You use these flags to verify whether methods were invoked. The mock class also contains public fields (such as the LoadStatesArgumentValue field) that you can query in your unit tests code. You use these public fields to analyze the parameters passed to the methods invoked by the presenter. The mock view also includes methods that raise events (such as the FireEditClicked method). You invoke these methods to test how the presenter reacts to events raised by the real view.

The following procedure describes how to create mock classes for the model.

To create mock classes for the model
  • If your presenter depends on model objects, such as services or controllers, create mock classes for these dependencies. To do this, create an interface for each dependency, and then implement the interface in your mock implementation (as you did for your mock view).
The Add Business Module recipe included in the Composite Web Client Automation generates a mock module controller class you can use in your presenter's unit tests. The mock module controller is stored in the Mocks folder of the module's test project.
  • If you must keep a reference to the concrete class in the presenter, you can create a mock class that extends the real class and overrides members. If you use this approach, you must have the real implementation of the dependency when you create the presenter.
  • For example, the Model-View-Presenter QuickStart includes a mock class named MockCustomersDataSource (located in Modules\Contacts.Tests\Mocks\MockCustomersDataSource.cs) that is used to replace the real customers data source implementation when testing the presenter. This class implements the same interface that the data source implements (the ICustomersDataSource interface.)
class MockCustomersDataSource : ICustomersDataSource
    public IList<Customer> GetCustomersReturnValue = new List<Customer>();
    public bool GetCustomersCalled = false;
    public List<State> GetStatesReturnValue = new List<State>();
    public bool GetStatesCalled = false;
    public Customer UpdatedCustomerValue;
    public bool UpdateCustomerCalled = false;

    public IList<Customer> Customers
            GetCustomersCalled = true;
            return GetCustomersReturnValue;

    public ICollection<State> States
            GetStatesCalled = true;
            return GetStatesReturnValue;

    public void UpdateCustomer(Customer customer)
        UpdateCustomerCalled = true;
        UpdatedCustomerValue = customer;

The following procedure describes how to implement the unit tests for the presenter.

To implement unit tests for the presenter
  • Use the mock objects you created in the previous procedures to create your unit tests. For example, the following code extracted from the Model-View-Presenter QuickStart illustrates the kind of unit test code you can create. The test method verifies that the ContactDetailPresenter class invokes the LoadStates method in the view when the OnViewInitialized method is invoked in the presenter and that it calls the GetStates method in the customers data source.
public class ContactDetailPresenterTestFixture
    MockCustomersDataSource dataSource;
    MockContactsController controller;
    ContactDetailPresenter presenter;
    MockContactDetailView view;

    public ContactDetailPresenterTestFixture()

    public void MyTestInitialize()
        dataSource = new MockCustomersDataSource();
        controller = new MockContactsController();

        view = new MockContactDetailView();
        presenter = new ContactDetailPresenter(view, dataSource);
        presenter.Controller = controller;

    public void OnViewLoadedLoadStates()
        dataSource.GetStatesReturnValue.Add(new State("WA","Washington"));


        Assert.IsTrue(view.LoadStatesArgumentValue.Count > 0);

    // ...

In the LoadStatesOnInitialization test method, a mock data source and a mock view are used. Both mock objects are initialized in the MyTestInitialize method. In the first line of the LoadStatesOnInitialization method, the mock data source is set up with a State object; the mock data source will return this object when the GetStates method is invoked. After that, the OnViewInitialized method is invoked on the presenter and three assertions are performed to verify the interaction of the presenter with the view and the data source:
  • Assert.IsTrue(dataSource.GetStatesCalled). This assertion verifies that the presenter called the GetStates in the data source.
  • Assert.IsTrue(view.LoadStatesCalled). This assertion verifies that the presenter invoked the LoadStates method on the view.
  • Assert.IsTrue(view.LoadStatesArgumentValue.Count > 0). This assertion verifies that the presenter passed a non-empty collection of State objects to the LoadStates method.
For more code examples, see the Model-View-Presenter QuickStarts.


You will have the following elements in your solution:
  • A mock view
  • Mock classes for dependencies of the presenter
  • Unit tests for the presenter
Model-View-Presenter pattern description | How to: Implement the Model-View-Presenter Pattern | Model-View-Presenter QuickStarts

Last edited Dec 5, 2007 at 12:43 PM by ejadib, version 1


No comments yet.