Castle, Rhino, Mocking, and Possibly You

So here’s the issue, you have a class that you new up within a class.

class SomeClass
{
  private HelperClass someHelperClass;

  public SomeClass()
  {
    someHelperClass = new HelperClass();
  }

  public String DoSomething()
  {
    return someHelperClass.DoSomeThing();
  }
}

You with me? Cause if you’re not, you’ve probably made a serious error in career choice.

Now what’s the problem with that situation? Testing. That SomeClass is tightly coupled with the HelperClass so that if you want to unit test DoSomething, you’re kind of screwed. Why? Say HelperClass has a database connection or does something that would update the database? Do you really want to create bad data every time you run this test? Do you really want the overhead of creating those connections and who knows what else? If you answered yes, again reconsider your career.

Now you could do something like this:

class SomeClass
{
  ....
  public SomeClass(HelperClass injectAHelperClass) <-- Change is right here genius.
  {
    someHelperClass = injectAHelperClass;
  }
  ...
}

Next step would be to mock the HelperClass in a unit test and pass in the mock object. But there’s a deeper problem. Deeper than G.I. Joe public service announcements. Yes that deep. What if you can’t pass in a mock through the constructor?? What if that helper class is being newed (Yes that’s a f–king word on this site) up in something like an attribute? What if your hair were to spontaneously catch on fire? Well you are back in the world of hurt my friend, except the hair thing might be an improvement. For the other two, there is something that can help and it’s name is Castle.

What is Castle? Well besides a word, it’s a collection of lots of stuff that helps with anything from mocking to tooth aches, but for this example we only need something that allows instantiation from a config file.

Now you might ask, “How can I be awesome like this site?” to which I answer, “You can’t.” Defeated you now turn your eyes back to the dilema and ask, “Config file? Instantiate? What will that do for me?”

Imagine this if you will… and I know this kind of thinking hurts you but just hang in there… Suppose you have a factory method that creates a instance for you. Something like this:

class SomeClass
{
  ....
  public SomeClass()
  {
    someHelperClass = new ObjectFactory().Create<IHelperClass>();
  }
  ...
}

BUT HOW DO IT CREATE THEM OBJECT FROM INTERFACE? Good question, though horribly asked.

Now it might seem odd since I am using a factory to create a helper but I haven’t shown you how the factory finds what to create. What if I told you there’s a way that it would simple look to a config file and know the type to create? What if I told you that in your test project the factory would create MockHelperClass but in the ui project it creates a HelperClass like before? You might think it’s magic. You might think Over the Top is the best movie of all time. You would be wrong on both accounts.

Now the answer is here if you don’t feel like reading the rest, and I can’t really blame you since I stopped reading after the first paragraph. However, if you actually want to see some of the magic in writing, mush on.

First thing you need are four dlls are Castle.Core, Castle.DynamicProxy, Castle.MicroKernel, Castle.Windsor, and Castle.ImSorryButThePrincessIsInAnother. (THERE ARE FIVE DLLS) Ok so one of those is a lie, but I’ll leave it up to you to figure it out. You could use my example to get them or go to here and try to figure out where they are. Course you could also spin around in a chair for five minutes because that would be about as brilliant as not just using my easy to find example. Either way, you need them.

Next the example needs an interface. Why an interface? Because it’s simple. Could I do this with a class? Far as I know as long as it’s not sealed and the concrete object inherits it. However for this example, ITS A MOOT POINT BECAUSE I’M USING AN INTERFACE.

namespace CastleConfigTest.Interface
{
  public interface IBaseClassA
  {
    String ClassName();
  }
}

Wow, beautiful. If you’re getting teary over that, you’re weird but I appreciate the passion. Now what else I need is a concrete class that implements said interface.

namespace CastleConfigTest.Class
{
  public class ChildClassA : IBaseClassA
  {
    public String ClassName()
    {
      return "ChildClassA";
    }
  }
}

Good golly Miss Molly, that’s fantastic. Now what does this all mean? It means that somehow using a config I will magically turn IBaseClassA into ChildClassA. Now for the hell of it, and for the ease of it, I have a test too.

    [TestMethod]
    public void Create_ClassA()
    {
      var test = new ObjectFactory().Create();
      Assert.IsTrue(test.ClassName().Equals("ChildClassA"));
    }

Ok so wait, what’s this ObjectFactory? It’s a class I’ve created that uses an object (WindsorContainer) that uses a config file to pull in specified types into a collection. Now I could get into that class, but I’d rather do the config file real fast. It’s name? Castle.config. AMAZING

<configuration>
  <components>
    <component id="childClassA"
     service="CastleConfigTest.Interface.IBaseClassA, CastleConfigTest"
     type="CastleConfigTest.Class.ChildClassA, CastleConfigTest">
    </component>
  </components>
</configuration>

So what does that all mean? Really nothing complicated. ‘service’ says, “Look for this” and ‘type’ says “Replace with this”. (No it doesn’t literally say that in the config file so stop looking) What’s the point of that? Simple, for every project you can have a separate Castle.config with the same ‘service’ value but a different ‘type’ value meaning that at run time you can replace the IBaseClassA with any class that implements IBaseClassA. Say in the test project you have a config:

...
     service="CastleConfigTest.Interface.IBaseClassA, CastleConfigTest"
     type="CastleConfigTest.Class.MockClassA, CastleConfigTest">
...

Now anytime IBaseClassA is called upon, MockClassA is almost instantly called in it’s place. Kind of like a stunt man in any action movie involving Bill Nighy.

Now one thing of special note, and by special I mean far from it, it helps if you set the config to Copy Always so that you know where the file is when the project is built. You don’t have to do that if you don’t want to, just like you don’t have to take showers. It’s just makes life easier for everyone.

Seems all great and good, but slight issue… What’s ObjectFactory? Well, here it is:

  public class ObjectFactory
  {
    //Tell it where the config file is.  Yes this is hardcoded but get over it.  You
    //  can change that if you like.
    private const String fileLocation = @"C:\Development\CastleConfigTest\CastleConfigTest\bin\Debug\";

    //This is the config file name.  I really hope you could tell that already.
    private const String fileName = "Castle.config";
    private WindsorContainer container;

    public ObjectFactory()
    {
      //Create a new container with the config file.
      container = new WindsorContainer(new XmlInterpreter(fileLocation + fileName));

      //Get all types in the container that implement IBaseClassA and make them
      // transient... ie only when needed.  If you don't believe me, go here and apologize later.
      // I'm sure you're used to that anyhow.
      var controllerTypes =
        Assembly
          .GetExecutingAssembly()
          .GetTypes()
          .Where(item => typeof(IBaseClassA).IsAssignableFrom(item));
      //And this I stole from someone but I can't remmeber who
      //  I don't really care though because chances are it was someone important
      //  and there's as much of a chance of someone important reading this as
      //  me sprouting a second me and doubling the worthless content on this site.
      //  After all, double of infinite is just the same damn thing.
      //  Not to mention this world isn't ready for that much pretty.
      controllerTypes = from t in Assembly.GetExecutingAssembly().GetTypes()
                            where typeof(IBaseClassA).IsAssignableFrom(t)
                            select t;

      foreach (Type type in controllerTypes)
        container.AddComponentWithLifestyle(type.FullName, type, LifestyleType.Transient);
    }

    //And then this is the wondrous and obviously complex method used to do the creating.
    public T Create() where T : class
    {
      return (T)container.Resolve(typeof(T));
    }
  }

Wait what? That’s it? Well for the most part. Only thing that was difficult was the ObjectFactory, but that’s so easy even a… well you know the rest. And why wouldn’t you? That f–ing phrase has burned into your skull for the last 5 years and that’s a conservative guess. And yes, there is room for improvement so save your nerd rage typing. After all, you have plenty of room for improvement but you won’t see me fist typing a list of things with disgruntled comic fan boy like intensity.

Anyways, that’s the short of it and since I gave you an example somewhere crazy hidden in this mess I call a post, you should be able to pick it up from there. If you can’t, consult your physician because you most likely suffer from acute brain loss. Don’t worry though, you can still have a long career as a PowerPoint instructor.

And if you haven’t figured it out yet, this post is my April Fools joke.  Actual useful content on this site.  Don’t get used to it.