Monday, May 26, 2014

AutoMapper - IOC vs. Static Mapper

I've been using AutoMapper for almost a year and I never noticed that it has an interface for the mapping engine cleverly named IMappingEngine.  I stumbled upon this post by Jimmy Bogard.  In the post Jimmy shows how to use AutoMapper with an IoC (Inversion of Control) container and more specifically, StructureMap.

I'm in two minds over this matter.  Technically, a test written against code that uses the static AutoMapper mapper class would be considered integration tests.  You loose one tiny seam in your code... Additionally, code written in this manner will hide its dependency on the external mapper.  However, how big of a deal is it?  When writing code that uses dependency injection, we are always monitoring our constructors for injection bloat but that's a separate issue. On one hand, if I use the static over the injected, I have one less parameter in the class constructor.  On the other, I hide a dependency and I can't write a mock to verify that AutoMapper was called.

I've tried out both instances of this in my code and for now I'm leaning toward injection for one reason alone. I'm not a big fan of writing a test to find it's failing because I forgot to configure AutoMapper in my unit test. Having it in the constructor forces the issue and it reminds me to either write a mock for it or configure and inject the static mapping engine. Typically, when writing my unit tests I use Moq. However, sometimes mocking auto mapper seems to make little sense as the mapping is an integral part of the code. Interestingly, in the comments on Jimmy Bogard's post, there is a conversion about this very issue.

Which should you use?  The answer is, it depends...  What is important to you?  What are you trying to test?

In case you find yourself wanting to use your IoC container, here is an example from StackOverflow  on how to register the IMappingEngine for resolution in Unity. 

container.RegisterType<IMappingEngine>(new InjectionFactory(_ => Mapper.Engine));

This works with any static global configuration done using Mapper.CreateMap<>(). Just ensure that your configuration is called once before using the mapping engine.

XAML Parse Error: Failed to Create a Type from the Text

Recently, while working on a data template in XAML, I encountered this error:  

After lots of searching and testing, I found the issue. It ended up being with the following line:

It was missing the assembly name and that caused the error.  

Wednesday, May 21, 2014

Moqing Prism's EventAggregator

Writing unit tests against the Prism EventAggregator using Moq should be easy right?  After all there is the IEventAggregator interface, and all of our events are separate classes.

Below are two examples.  Example 1 verifies a certain event is published twice.
That is fairly simple, and it works!   Great, so what is the problem?

Example 2 shows how to trigger an event using Moq.  Imagine you have a subscription to an event, and the Action in the Subscribe() method is private.  Using Moq the event needs to be published and the system under test then needs to be examined for a change in state.

The key to example two seems to be this, a real event must be used not a mocked event.  I was able to find two separate examples for Rhino Mocks and adapt them to Moq. RhinoMock:Exp1 RhinoMock:Exp2

As a side note there is allot of information and miss-information surrounding Moq and IEventAggregator.

Stack Overflow: Moq Event Aggregator is it Possible?

Stack Overflow: Mocking Prism Event Aggregator using Moq for Unit Testing

Stack Overflow: How to verify Event Subscribed using Moq

CodePlex: Mocking Event Aggregator with MOQ

Note: As pointed out in the Stack Overflow post titled How to verify Event Subscribed using Moq, the only virtual call to Subscribe takes lots of parameters, so makes a messy looking test.  Not to mention even then its not working for me, need to get the call back parameters right, the parameters in the SO example make my test error.

Monday, May 12, 2014

Good API Design

As I've been working on a fairly large API design, several times I turned to the Internet searching for help verify or nullify design decisions I've made.   I ran across a Tech-Talk by Google engineer Joshua Block that has been extremely helpful.

Here is a link to the slides.

Saturday, May 3, 2014

Public API's - Using Dependency Injection (while avoiding user hate)

As many developers have discovered, Dependency Injection (DI) is a very useful pattern.  It allows a developer to see what dependencies a class has, or in simpler terms, it shows what other objects the object being constructed interacts with.  DI goes hand in hand with Inversion of Control (IoC), which allows us to set up a IoC container that will inject the correct dependency when needed.  This is all typically wired up at one place in an application called the application root.

One of the biggest reasons to use DI is testability.  It allows mocks to be injected into the classes constructor when testing.

What does all this have to do with building a public API?  Well, when your users go to use the library that you crafted with this best practice idea of DI, they may be in for a nasty surprise.   Some developers that don't want to be bothered with DI but want to use your framework.  The object graph wire-up may look something like this...

public class TheAPIConsumersClass
    Airport WireUpTheShinyNewAirportAPI()
       var fuel = new Fuel();
       var engine = new Engine(fuel);
       var prop = new Prop();
       var airplane = new AirPlane(engine,prop);
       var controlTower = new ControlTower();
       var airport = new Airport(airplane, controlTower);
       return airport;

When all your user really wants to do is this something like this...

public class TheAPIConsumersClass
    Airport WireUpTheShinyNewAirportAPI()
       var airport = new Airport();

I found myself in this situation with our API design recently.  I didn't want to lose the DI that I'd been using for testing, yet I didn't want to expose all the constructors to the users of the API.  After searching around the Internet, I came up with something I could live with.  

Mark the constructor with dependency injection as internal.  Have a public constructor which calls the internal constructor, provides the required dependencies.  

public class MyApi
   public MyApi() : this(new Thing1(), new Thing2())
  internal MyApi(Thing1 thing1, Thing2 thing2)
          _thing1 = thing1;
          _thing2 = thing2;

More food for thought...