Achieving unit testability of Presenter while using CSLA Framework with WCSF

Question

The WCSF uses Model View Presenter (MVP) pattern for organizing/structuring the source code for a website. When MVP pattern is used correctly, it provides seperation of concerns, unit testability of presenter logic, etc.

How to make WCSF and CSLA framework play well (work together) for achieving unit testability of the presenter logic. For achieving the unit testability of the presenter logic it is required that all data access and other dependencies needs to be mocked or stubbed out.

Answer 1

When executing the data portal methods within a CSLA object, the content of those data portal methods should call dataservices to get and update that data. Those web services should just be interface based so that they can be mocked out.

Here is an example of populating an employee object:

private void DataPortal_Fetch(SingleCriteria<Employee, int> criteria)
{
  IEmployeeDTO data = DataServiceContext.Current.EmployeeDataService.GetEmployee(criteria.Value);
  // Just do left to right copying here
  LoadProperty<int>(IdProperty, data.Id);
}

Then EmployeeDataService is just an interface. We use Ninject to create a concreate class for that interface that will point to another assembly for the data access technology you want to use. You can then specify a different concrete class for the test class.

Here is the example data service interface:

public interface IEmployeeDataService
{
  IEmployeeDTO GetEmployee(int id);
}

Here is the example data service concreate class for using Linq 2 SQL:

namespace XXX.DataServices.Linq
{
  public class EmployeeDataService : IEmployeeDataService
  {
    public IEmployeeDTO GetEmployee(int id)
    {
      // use Linq to SQL to get the data and transform that class into IEmployeeDTO
    }
  }
}

Here is the example data service to use for testing:

namespace XXX.DataServices.Testing
{
  public class IEmployeeDTO GetEmployee(int id)
  {
    // mock up several IEmployeeDTO objects with known data
  }
}