In my last post on unit testing, I had written about a technique I'd learnt forsimplifying test set ups with the builder pattern. It provides a higher level, more readable API resulting in DAMP tests.
Implementing it though presented a few interesting issues that were fun to solve and hopefully, instructive as well. I for one will need to look it up if I spend a few months doing something else - so got to write it down :).
In Scheduler user portal, controllers derive from the MVC4
Let's start from how we'd like our API to be. So, for something that just requires HTTP context, we'd like to say:
Writing
Hmm - so a little refactoring is in order. A base
But this won't compile: :(
But this does muck up our builder API's chainability - telling clients to call methods in certain arbitrary sequence is a no - no. And this is where extensions provide a neat solution. Its in two parts
Implementing it though presented a few interesting issues that were fun to solve and hopefully, instructive as well. I for one will need to look it up if I spend a few months doing something else - so got to write it down :).
In Scheduler user portal, controllers derive from the MVC4
Controller class whereas others derive from a custom base Controller. For instance, Controllers that deal with logged in interactions derive from TenantController which provides TenantId and SubscriptionId properties. IOW, a pretty ordinary and commonplace setup. class EventsController : Controller
{
public ActionResult Post (MyModel model)
{
// access request, form and other http things
}
}
class TenantController: Controller
{
public Guid TenantId {get; set;}
public Guid SubscriptionId {get; set;}
}
class TaskController: TenantController
{
public ActionResult GetTasks()
{
// Http things and most probably tenantId and subId as well.
}
}
EventsController will require HTTP setup (request content, headers etc) where as for anything deriving from TenantController we also need to be able to set up things like TenantId.Builder API
Let's start from how we'd like our API to be. So, for something that just requires HTTP context, we'd like to say:
controller = new EventsControllerBuilder()
.WithConstructorParams(mockOpsRepo.Object)
.Build();
TenantController: controller = new TaskControllerBuilder()
.WithConstructorParams(mockOpsRepo.Object)
.WithTenantId(theTenantId)
.WithSubscriptionId(theSubId)
.Build();
this to facilitate chaining. Apart from that, it has a Build method which builds a Controller object according to the different options and then returns the controller. Something like this: class TaskControllerBuilder()
{
private object[] args;
private Guid tenantId;
public TaskControllerBuilder WithConstructorParams(params object args )
{
this.args = args;
return this;
}
public TaskControllerBuilder WithTenantId(Guid id )
{
this.tenantId = id;
return this;
}
public TaskController Build()
{
var mock = new Mock<TaskController>(MockBehavior.Strict, args);
mock.Setup(t => t.TenantId).Returns(tenantId);
return mock.Object;
}
}
Generics
Writing
XXXControllerBuilder for every controller isn't even funny - that's where generics come in - so something like this might be easier: controller = new ControllerBuilder<EventsController>()
.WithConstructorParams(mockOpsRepo.Object)
.Build();
class ControllerBuilder<T>() where T: Controller
{
private object[] args;
private Guid tenantId;
protected Mock<T> mockController;
public ControllerBuilder<T> WithConstructorParams(params object args )
{
this.args = args;
return this;
}
public T Build()
{
mockController = new Mock<T>(MockBehavior.Strict, args);
mockController.Setup(t => t.TenantId).Returns(tenantId);
return mock.Object;
}
}
Controller, we do not have the TenantId or SubscriptionId properties in the Build method.Hmm - so a little refactoring is in order. A base
ControllerBuilder that can be used for only plain controllers and a sub class for controllers deriving from TenantController. So lets move the tenantId out of the way from ControllerBuilder. class TenantControllerBuilder<T>: ControllerBuilder<T>
where T: TenantController // and this will allow access
// TenantId and SubscriptionId
{
private Guid tenantId;
public TenantControllerBuilder<T> WithTenantId(Guid tenantId)
{
this.tenatId = tenantId;
return this;
}
public T Build()
{
// call the base
var mock = base.Build();
// do additional stuff specific to TenantController sub classes.
mockController.Setup(t => t.TenantId).Returns(this.tenantId);
return mock.Object;
}
}
/// This will work:
controller = new TenantControllerBuilder<TaskController>()
.WithTenantId(guid) // Returns TenantControllerBuilder<T>
.WithConstructorParams(mockOpsRepo.Object) // okay!
.Build();
But this won't compile: :(
///This won't compile:
controller = new TenantControllerBuilder<TaskController>()
.WithConstructorParams(mockOpsRepo.Object) // returns ControllerBuilder<T>
.WithTenantId(guid) // Compiler can't resolve WithTenant method.
.Build();
ControllerBuilder, then the derived class cannot provide a stricter contract that it will provide not only a ControllerBuilder but that it will only be TenantControllerBuilder.But this does muck up our builder API's chainability - telling clients to call methods in certain arbitrary sequence is a no - no. And this is where extensions provide a neat solution. Its in two parts
- Keep only state in
TenantControllerBuilder. - Use an extension class to convert from
ControllerBuildertoTenantControllerBuildersafely with the extension api.
// Only state:
class TenantControllerBuilder<T> : ControllerBuilder<T> where T : TenantController
{
public Guid TenantId { get; set; }
public override T Build()
{
var mock = base.Build();
this.mockController.SetupGet(t => t.TenantId).Returns(this.TenantId);
return mock;
}
}
// And extensions that restore chainability
static class TenantControllerBuilderExtensions
{
public static TenantControllerBuilder<T> WithTenantId<T>(
this ControllerBuilder<T> t,
Guid guid)
where T : TenantController
{
TenantControllerBuilder<T> c = (TenantControllerBuilder<T>)t;
c.TenantId = guid;
return c;
}
public static TenantControllerBuilder<T> WithoutTenant<T>(this ControllerBuilder<T> t)
where T : TenantController
{
TenantControllerBuilder<T> c = (TenantControllerBuilder<T>)t;
c.TenantId = Guid.Empty;
return c;
}
}
///This now works as intended
controller = new TenantControllerBuilder<TaskController>()
.WithConstructorParams(mockOpsRepo.Object) // returns ControllerBuilder<T>
.WithTenantId(guid) // Resolves to the extension method
.Build();