Here is another gem from the message boards (thanks to Justin Burtch):
One of the advantages of MVP is that it allows easier unit-testing. For this you need to declare all public methods of view that the presenter uses as an interface, and then you can easily substitute the actual view with its mock implementation. But to test all your components properly you need to run them in the same environment as when you run it in a GUI. By this I mean that you have some WorkItem that adds these items into the ManagedObjectCollections of the WorkItem. The WorkItem internally uses the ObjectBuilder to create the objects and initialize the properties as specified in the attributes that adorn the properties.
In the VSTS Test project for CAB, there is an object called TestableRootWorkItem. Create one of those and then add the view and controller into it's Items collection. That will get the ServiceDependency to be detected and initialized. Though the initialization you are doing by adding this WorkItem into the mix means that you're testing the CAB dependency injection framework and without a little manipulation of configuration of services, you are also testing your service. Just means that if the test breaks, you have a couple of classes you have to investigate.
Here is one example of such test from the SC-BAT project:
[TestMethod]
public void ShowAppraisalCalledInResponseToEventBrokerEvent()
{
TestableRootWorkItem wi = new TestableRootWorkItem();
wi.Services.AddNew();
AppraisalDetailPresenter presenter = wi.Items.AddNew();
MockView view = new MockView();
presenter.View = view;
wi.EventTopics[Constants.EventTopics.WorkingAppraisalSelected]
.Fire(this, new DataEventArgs("1"), wi, PublicationScope.Global);
Assert.IsTrue( view.ShowAppraisalWasCalled);
}