Question

I’m working on a project where there is a lot of external service messaging. A good way to describe it in only a slightly ‘hyperbolas’ way would be an application where the system has to send messages to the Flicker API, the Facebook API, and the Netflix API.

To support disconnected scenarios, logging concerns, developer usability, configuration, etc… I’ve experimented using an approach which heavily uses generics and expression trees. The end result looks like this:

Messenger<NetflixApi>.SendCustom( netflix => netflix.RecommendMovie('my message')); 

Overall I’m happy with the end result but feel like I’ve made a mistake, or overlooked a design principal someplace with regards to testing and disconnected scenarios.

During testing, whether automated, unit, or human based, I’ve implemented an object factory that initially uses DI to perform the correct action in ‘Live mode’ and used Mocks to provide a sort of sterile messenger that doesn’t do anything at all when in a testing mode.

I’ve only seen or read about Mocks being used in pure TDD mode and not being used to be sort of a dumb object. The approaches I’ve seen would revolve around stubbing or mocking out the HTTP communication functionality which all the APIs I’m using depend on.

My main concern is that will all the different services I expect to connect to I’d end up having to do a lot of granular work substituting specific HTTP implementation and if I used a stub approach I’d have 3 classes for each of these services( IService, ConcreteService, StubService ) and maintaining those when implementing a new method or changing anything would be a real PITA.

In the current implementation I’m using Mocks to get ‘sterile mode’ for free almost without having to implement anything extra just to conform to a certain testing principal.

The question is am I missing something? Did I violate a design principal using Mocks in a more… convenient way?

Can anybody offer any advice on how to get a sterile mode out of many different outside services without jumping through a lot of hoops?

Does this question make sense?

Thanks for all the answers.

Edit #1:

I wasn’t clear in my original question. Any null or mock objects are to be used purely in a development/debug/testing environment. In production the code that sends these messages will be the actual implementation of them.

I voted everybody up because there seem to be a lot of different solutions to this problem and I’ll be exploring each one.

Please don’t think this question has been answered yet, I’d appreciate as much advice as I can get.

Answer 1

There is a design pattern called Null Object. A null object is an object that implements a Interface, so it could be used in an scenario like yours.

The important thing about the Null Object is that DON’T return null in places where that could break the system.

The purpose of the Null Object is to have a void and simple implementation of something, just like a Mock, but to be used in the production environment.

The most simple example is something like this:

class Logger{  private static ILogger _Logger;   static Logger(){   //DI injection here   _Logger = new NullLogger(); //or   _Logger = new TraceLogger();  } }  interface ILogger{  void Log(string Message); }  internal class TraceLogger:ILooger{  public void Log(string Message){   //Code here  } }  internal class NullLogger{  public void Log(string Message){   //Don't don anything, in purporse  } } 

I hope this could help you