WorkItemController & testability

Topics: CAB & Smart Client Software Factory
May 8, 2007 at 9:41 AM
I've read a lot about how the WorkItemController class is supposed to help testability by abstracting away the WorkItem which is very CAB, and leaving a derived WorkItemController which contains the business logic for the use-case... But haven't found much more written on the topic!

Is my understanding correct:

MyWorkItemController creates smartparts, sub-workitems, etc. that are required to carry out its business case.
It subscribes to events from these items
You then add "testable" methods which encapsulate the business logic.
You can mock out the various presenters for testing interactions to the Presenters.

(Question - how would you test sub work items ( ControlledWorkItem<MyController> ). You can't mock these out as ControlledWorkItem<IMyController>. Should Controllers only talk via Events?

public class MyWorkItem: WorkItemController
  //This could be mocked / use a testing impl for the test framework
  private IView1Presenter _view1Presenter;
  public override void Run()
    //plugs into the CAB framework to create smart-parts, etc.
    _view1Presenter = WorkItem.SmartParts.AddNew<View1>().Presenter;
  public void OnFoo(object sender, EventArgs<CustomerCriteria> e)
  public void UsefulBitOfBusinessLogic(CustomerCriteria criteria)
    //I can test this method without CAB
    //But if it does something like asking a SmartPart to update its view how would that be tested given that
    //my test framework won't have created the view?

May 8, 2007 at 2:28 PM
If you look at CompositeUI tests you will find a TestableWorkItem. This workitem can be used as the root testable workitem. You can add mocks smartpart there and your controlledworkitems and then check that when you call a certain method of the workitemcontroller, a specific smartpart is added to the workitem and/or a specific event is fired and/or a specific methods of the smartpart (which is mocked) has been called.