How to Use a Factory Method With Castle / WindsorContainer

In my last post, I showed you the wonder of the WindsorContainer and creating concrete objects from a config file… but I wasn’t done yet. In fact, if you looked at my example and used your keen sense of observation (I’m suspending my disbelief) you might have noticed a little somethin’ somethin’ in the config file that I didn’t explain:

  <component id="factoryB"
    type="CastleConfigTest.Factory.FactoryB, CastleConfigTest">
  </component>

  <component id="childClassB"
   type="CastleConfigTest.Interface.IBaseClassB, CastleConfigTest"
   factoryId="factoryB"
   factoryCreate="Create">
  </component>

And:

  <facilities>
    <facility id="factorysupport" type="Castle.Facilities.FactorySupport.FactorySupportFacility, Castle.Microkernel" />
  </facilities>

What are these??? Could they be the proof of intelligent life we’ve been looking for? Sadly no, since they actually are part of something that sounds a lot more complicated then it is. Say you have this interface:

  public interface IBaseClassB
  {
    String ClassName();
  }

And this class:

  public class ChildClassB : IBaseClassB
  {
    public String ClassName()
    {
      return "ChildClassB";
    }
  }

Which is all pretty straight forward much like that woman’s answer to you asking her out, “God no.”

If you had read this post, you might guess where this is going. Or you might guess that I’m going to re-explain it because you are too lazy to go and read it. One of those is correct.

Once again like my last post I do something simple like this:

  var test = new ObjectFactory().Create<IBaseClassB>();

And what I get is a brand new shiny ChildClassB. I can hear the yawns from here SO I’ll change it up a bit. What if I need ChildClassB to come from a Factory? How the hell would I pull that off?

  public class FactoryB
  {
    public static IBaseClassB Create()
    {
      var test = new ChildClassB();
      //Do some stuff to test
      return test;
    }
  }

I no longer can just replace IBaseClassB with ChildClassB directly because I need FactoryB to do something for me first. (I cheated by just adding a comment where code might go.  Point is, something happens to ChildClassB before the factory returns it.) OH NO! WHAT AM I TO DO? HOW CAN I SOLVE THIS? DOES THE CAPSLOCK ADD SUSPENSE?

Guess what? That’s right, that’s where that config stuff at the top comes in. Here’s the config file in full:

<configuration>
  <components>
    <component id="factoryB"
      type="CastleConfigTest.Factory.FactoryB, CastleConfigTest">
    </component>
    <component id="childClassB"
     type="CastleConfigTest.Interface.IBaseClassB, CastleConfigTest"
     factoryId="factoryB"
     factoryCreate="Create">
    </component>
  </components>
  <facilities>
    <facility id="factorysupport" type="Castle.Facilities.FactorySupport.FactorySupportFacility, Castle.Microkernel" />
  </facilities>
</configuration>

Ok so I lied, that’s not the full thing I have in my example that you can download, but it is what you need for this part. It’s actually pretty simple too. You just need to declare three things:

The factory class “FactoryB”

    <component id="factoryB"
      type="CastleConfigTest.Factory.FactoryB, CastleConfigTest">
    </component>

The interface you want to mask with the factory return (IBaseClassB)

    <component id="childClassB"
     type="CastleConfigTest.Interface.IBaseClassB, CastleConfigTest"  //This is the interface to look for
     factoryId="factoryB"  //This is the id from above where you declared the factoryB section
     factoryCreate="Create">  //This is the method to use
    </component>

and the Castle part for using factories

  <facilities>
    <facility id="factorysupport" type="Castle.Facilities.FactorySupport.FactorySupportFacility, Castle.Microkernel" />
  </facilities>

And that’s really it. From that, this should work:

    [TestMethod]
    public void Create_ClassB()
    {
      //This will call FactoryB.Create to create the ChildClassB for me
      var test = new ObjectFactory().Create();
      Assert.IsTrue(test.ClassName().Equals("ChildClassB"));
    }

Woo hoo! Now you can run home and impress your Wife/Husband/fiance/partner/thing that lives in your apartment and always seems to pay the rent late but doesn’t have any issue with eating everything in your fridge! Enjoy!

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.

Dictionary Index Lookup Vs Contains Key Vs List Contains Vs Linq… Speed Test/Texas Tornado Match

Ok so with MVC comes the use of Routes which calls in the need to compare request values to see which route to use. Now before I even bother with that headache (Although it’s getting better AND will be a post) I ran into a situation where I would have to check a passed in string against a list of strings to see if it matches any of them.

One thing I like to do is use Dictionaries. They are just plain convenient when it comes to looking things up or matching values to get methods. But what if I don’t really have a value to find with a key? What if finding the key is all that matters? Say I have a list of strings and I just want to know if the list contains that string, sounds like a job for an array or list right? Wouldn’t it be silly to create a dictionary like:

  Dictiontary<String, String> someList = new Dictiontary<String, String>();
  someList.Add("INeedThis", ""); someList.Add("ThisToo", "");

and do this:

  if(someList.ContainsKey("INeedThis"))

If I don’t actually care about the attached value? I’m sure I’m breaking a rule somewhere… but what if it was faster overall? What if ContainsKey is faster than a list using Any, Contains, FirstOrDefault, or where? Turns out it is. Here’s the method I used.

  public void TimeRun(Holder toHold)
  {
    Int32 maxLength = 1000;

    Dictionary<String, String> stringDictionary = Enumerable.Range(0, maxLength).Select(item => RandomTool.RandomString(item)).ToDictionary(item => item, item => item);
    List<String> stringList = stringDictionary.Select(item => item.Key).ToList();

    String chosenString = stringList[RandomTool.RandomInt32(0, maxLength)];

    Stopwatch runTime = new Stopwatch();

    runTime.Start();
    stringDictionary.ContainsKey(chosenString);
    runTime.Stop();
    toHold.DictionaryContainsKeyTime = runTime.ElapsedTicks;
    runTime.Reset();

    runTime.Start();
    String junk = stringDictionary[chosenString];
    runTime.Stop();
    toHold.DictionaryStraightIndexCheck = runTime.ElapsedTicks;
    runTime.Reset();

    runTime.Start();
    Boolean junkThree = stringList.Contains(chosenString);
    runTime.Stop();
    toHold.ListContains = runTime.ElapsedTicks;
    runTime.Reset();

    runTime.Start();
    Boolean junkTwo = stringList.Any(item => item == chosenString);
    runTime.Stop();
    toHold.ListLinqAny = runTime.ElapsedTicks;
    runTime.Reset();

    runTime.Start();
    String junkFour = stringList.First(item => item == chosenString);
    runTime.Stop();
    toHold.ListLinqFirst = runTime.ElapsedTicks;
    runTime.Reset();

    runTime.Start();
    IEnumerable<String> junkFive = stringList.Where(item => item == chosenString);
    if (junkFive.FirstOrDefault() != String.Empty)
    {

    }
    runTime.Stop();
    toHold.ListLinqWhere = runTime.ElapsedTicks;
    runTime.Reset();
  }

Crazy simple, and why shouldn’t it? Am I right? Am I right? Ok. As you can see, I gave all the methods a run and timed them using StopWatch. And then I ran it a given amount of times, 200 in this code but I tried up to 10000 also. (I’ll put the test code at the end) The test was to go through a list of a thousand strings, each string increasing in length. (Yeah I could have done random size strings but I’m lazy)

What did I find out? Well if it didn’t throw an exception, a straight index search on a dictionary is fastest:

someList["INeedThis"]

And pretty consistently fast. Around 2600 ticks or so on average on multiple runs. (so 10 iterations of parent method running 200-10000 interations of the test method) Next fastest was the ContainsKey method on the dictionary, usually around 2-4 times faster than the next in line good old List.Contains. What I did find surprising is that all the Linq methods failed on this one. I figured that once the first run was through, it would be at least as fast as Contains. (Linq always sucks the first time through) Yeah not so much though. Contains was always faster. Sometimes it was close. Sometimes not even. Here are some example runs:

Dictionary_ContainsKey: 15805
Dictionary_StraightIndexCheck: 2926
List_Contains: 34559
List_LinqAny: 96575
List_LinqFirst: 56541
List_LinqWhere: 64678 

Dictionary_ContainsKey: 7264
Dictionary_StraightIndexCheck: 2676
List_Contains: 29970
List_LinqAny: 41280
List_LinqFirst: 58313
List_LinqWhere: 45669 

Dictionary_ContainsKey: 6773
Dictionary_StraightIndexCheck: 2636
List_Contains: 32366
List_LinqAny: 38670
List_LinqFirst: 33859
List_LinqWhere: 41288

All in ticks. Now mind you, none of these are horribly slow so it probably just comes down to reability and ease of understanding. Personally I like the Dictionary way, so at least speed wise I’m on track. As for looks? That’s a personal thing.

Rest of the code. Here is the parent method. This is a unit test hense the .Assert but it could easily be adapted to any output.

  [TestMethod]
  public void RunTime()
  {
    Int64 overallDictionaryContainsKeyTime = 0;
    Int64 overallDictionaryStraightIndexCheck = 0;
    Int64 overallListContains = 0;
    Int64 overallListLinqAny = 0;
    Int64 overallListLinqFirst = 0;
    Int64 overallListLinqWhere = 0;
    Int32 loopMax = 200;

    for (Int32 loopCounter = 0; loopCounter < loopMax; loopCounter++)
    {
      Holder currentHolder = new Holder();

      TimeRun(currentHolder);
      overallDictionaryContainsKeyTime += currentHolder.DictionaryContainsKeyTime;
      overallDictionaryStraightIndexCheck += currentHolder.DictionaryStraightIndexCheck;
      overallListContains += currentHolder.ListContains;
      overallListLinqAny += currentHolder.ListLinqAny;
      overallListLinqFirst += currentHolder.ListLinqFirst;
      overallListLinqWhere += currentHolder.ListLinqWhere;
    }

    Assert.IsTrue
    (
      false,
      " Dictionary_ContainsKey: " + (overallDictionaryContainsKeyTime / loopMax) +
      " Dictionary_StraightIndexCheck: " + (overallDictionaryStraightIndexCheck / loopMax) +
      " List_Contains: " + (overallListContains / loopMax) +
      " List_LinqAny: " + (overallListLinqAny / loopMax) +
      " List_LinqFirst: " + (overallListLinqFirst / loopMax) +
      " List_LinqWhere: " + (overallListLinqWhere / loopMax)
    );
  }

And the holder class which is a nothing class. I just didn’t care for having to add parameters to the child mehod.

  public class Holder
  {
    public Int64DictionaryContainsKeyTime { get; set; }
    public Int64DictionaryStraightIndexCheck { get; set; }
    public Int64ListLinqAny { get; set; }
    public Int64ListContains { get; set; }
    public Int64ListLinqFirst { get; set; }
    public Int64ListLinqWhere { get; set; }
  }

Couple Notes:

  • StopWatch is in System.Diagnostics
  • RandomTool is actual a class of mine. Nothing special about it. Just makes a string of X length with all random letters.
  • This can not be rebroadcast or retransmitted without the express written permission of my mom.

Filling a Private Field on a Base Class Using Reflection

Ok here’s the next step in this testing kick. So now you have your test classes that create classes. Swell. Problem is, there are private fields on the base class of whatever class you are creating. So you’re screwed, right? Not really. Now what I am about to do is nothing new. It’s just basically using Reflection and FieldInfo to fill a field on a base class. Actually very easy. Here’s the code for the example.

using System;
using System.Collections.Generic;
using System.Reflection;

public class UserBase
{
  private Boolean _isBaseUser;

  public UserBase()
  {
      _isBaseUser = true;
  }

  public Boolean IsBaseUser
  {
      get
      {
          return _isBaseUser;
      }
  }
}

public class MainUser : UserBase
{
  //Simple list used to "cache" the field info so reflection doesn't have to be used
        //again for a type that has already been used.
  private static Dictionary<Type, List<FieldInfo>> typeToInfoList;

  /// <summary>
        /// This is used to fill in the needed field on the passed in object.  This is done by reflection/
        /// FieldInfo.  Basically you get the field info you want off the type, then you use the info to
        /// fill the field on the object.  
        /// </summary>
        /// <param name="objectToFill">This is the object that needs the field changed.</param>
        /// <param name="fieldName">This is the name of the field.</param>
        /// <param name="value">This is the value to be set.</param>
        /// <param name="typeToCheck">This is the type of the class that the field resides.</param>
  public static void FillField(Object objectToFill, String fieldName, Object value, Type typeToCheck)
  {
      List<FieldInfo> fieldInfoList;
      FieldInfo neededFieldInfo;
      Boolean heldInfoList;

      if (typeToInfoList == null)
      {
          typeToInfoList = new Dictionary<Type, List<FieldInfo>>();
      }
      //Check to see of the list already has the field info and save that 
          //boolean for later use.
      heldInfoList = typeToInfoList.ContainsKey(typeToCheck);
      //If it is in the "cache", grab it.  If not, create a new list
          //for the passed in type.
      fieldInfoList = heldInfoList ? typeToInfoList[typeToCheck] : new List<FieldInfo>(typeToCheck.GetFields(BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.Public));

     //Now just look for the needed field info in the list. 
     neededFieldInfo = fieldInfoList.Find(currentItem => currentItem.Name == fieldName);
      //Use the field info to set the value on the object.
      neededFieldInfo.SetValue(objectToFill, value);

      //Store the field info list if it isn't being stored already.
      if (!heldInfoList)
      {
          typeToInfoList.Add(typeToCheck, fieldInfoList);
      }
  }

  //Simple constructor to create the user.
  public static MainUser Create()
  {
      MainUser testUser;

      testUser = new MainUser();

      return testUser;
  }
}

That’s pretty much it. What the hell is all that? Well basically you have the UserBase as the base class for the example. MainUser that in inherits UserBase. The FillField method that does all the work. And lastly, the dictionary used as a lame cache for this example. Why cache anything? Well everything you get the field info, reflection is used. This can be expensive. So why bother getting the same field info for the same type every time this method is called? Just store it somewhere so that if the same class type is passed through again, you can easily access the field info for the class without going for reflection again.

Here’s an example of the use:

using Microsoft.VisualStudio.TestTools.UnitTesting;

 [TestClass]
 public class FillFieldTest
 {
     [TestMethod]
     public void FillField_CheckFieldForChange()
     {
         MainUser testUser;

         testUser = new MainUser();
         Assert.IsTrue(testUser.IsBaseUser);

         MainUser.FillField(testUser, "_isBaseUser", false, typeof(UserBase));
         Assert.IsFalse(testUser.IsBaseUser);

         MainUser.FillField(testUser, "_isBaseUser", true, typeof(UserBase));
         Assert.IsTrue(testUser.IsBaseUser);
     }
 }

First test is checking to see if the IsBaseUser property is true. This will be true since UserBase sets _isBaseUser to true on instantiation.

Second test is checking to see if the FillField method worked correctly.

Third test is really just to step through a second time so you can see how the quasi-caching works.

Mulitple Constraint Generics and Test Base Classes

This was basically an idea I had to have test classes inherit a TestBase that has a Static Create method on it. The reason for this is that I have found it easier to have a Create method that takes care of creating a temporary class of the type the test represents. Say I have a UserTest class and I need an address. Instead of creating and filling a whole address object in the UserTest, it easier to have a Create Method on the AddressTest class that gives me a premade Address object. Why would I want to redo a lot of the same code by having the create method on every class when I can have it on a base class and just have the non base classes specify how to create the object?

Is this really needed? I can’t argue absolutely, but this forces a Create method to appear on any test class that inherits from TestBase and by use of Exceptions, forces the child classes to define how to create the object they represent. (As in it forces AddressTest to define how to create an Address object.) This also allows the Create method to be static and inherited. You could make it abstract, to skip the need for the two create methods(Create and CreateInstance), but that would hose the whole situation since static abstract is a no no. Static is a must for this situation.

The idea behind the code is to have a static Create method on the TestBase class that when called will create the test class type passed in through generics.

public static I Create()
 {
     I returnValue;
     J testToUse;

     testToUse = System.Activator.CreateInstance<J>();
     returnValue = testToUse.CreateInstance();

     return returnValue;
 }

Where J is the test class type to create. Once that test class is instantiated, the virtual method CreateInstance is called. This is where the test class creates the instance of the object it represents.

protected override I CreateInstance()
{
     I returnValue;

     returnValue = (I)new SimpleItem();
     returnValue.IsSimple = true;
     return returnValue;
}

Where I is the type of object it is going to create. In use it will look something like this:

  ItemBase itemToCreate;

  itemToCreate = SimpleItemTest<SimpleItem>.Create();

Now for the code:

//Some junk base items to demostrate the creating of an item with a base class
public class ItemBase 
{
}

//One item that will be created
public class SimpleItem : ItemBase
{
 public Boolean IsSimple { get; set; }
}

//The other item that can be created.
public class ComplexItem : ItemBase
{
 public Boolean IsComplex { get; set; }
 public Boolean IsNotSimple { get; set; }
}

//This test will be used to create a SimpleItem
public class SimpleItemTest<I> : TestBase<I, SimpleItemTest<I>> where I : SimpleItem
{
 protected override I CreateInstance()
 {
     I returnValue;

     returnValue = (I)new SimpleItem();
     returnValue.IsSimple = true;
     return returnValue;
 }
}

//This test will be used to create a ComplexItem
public class ComplexItemTest<I> : TestBase<I, ComplexItemTest<I>> where I : ComplexItem
{
 protected override I CreateInstance()
 {
     I returnValue;

     returnValue = (I)new ComplexItem();
     returnValue.IsComplex = true;
     returnValue.IsNotSimple = true;
     return returnValue;
 }
}

//This is the base class where the Create Method resides
public class TestBase<I, j> where I : class where J : TestBase<I, j>
{
 //This will either be overridden or throw an error.  Kind of a forced
 //abstract.  This is the method that the child test classes will use to
 //create whatever class they represent.
 protected virtual I CreateInstance()
 {
     throw new System.NotImplementedException();
 }

 //This is used to create a test class and call the CreateInstance method
 //so that this method can return the correct object.  The object type is
 //dependent on the type of test class that is being created.
 public static I Create()
 {
     I returnValue;
     J testToUse;

     testToUse = System.Activator.CreateInstance<J>();
     returnValue = testToUse.CreateInstance();

     return returnValue;
 }
}

Test Projects and Unit Tests In Visual Studio 2008

A quick thing about setting up test projects through Visual Studios… basically how to do so.

Add new Project -> Test (Project Types) -> Test Project.

Now the easiest way I’ve added actual tests is just to add a normal class. Say SomeClassTest.


using Microsoft.VisualStudio.TestTools.UnitTesting;

[TestClass]
public class SomeClassTest()
{
   [TestMethod]
   public void SomeClass_CreateWithNull()
   {
   }
}

What is [TestClass]? Well that is an attribute you are adding to the class so that .net knows certain methods in it may be test methods. Guess what [TestMethod] does…

Ok so now I have a TestClass and TestMethod, now what? Well in the menu:

Test -> Windows -> TestView

You should see that your method now shows up on the list. Simple huh? If the method isn’t showing up on the list make sure it is:

  • Tagged with the [TestMethod] attribute
  • Contained in a PUBLIC [TestClass]
  • Public
  • void
  • Non static

If you have all of those and still nothing, right click the method name in the Test View and look at it’s properties. There is a property called “Non-Runnable Error”. This will tell you what you need to get it rolling.

All right, now you have everything set… so next? Simple, right click the method name in the Test View and you can either Run or Debug the test. If you just Run the test, the Test Results window will pop up and you’ll see the progress. If it passes, then yay. If not, it will give you things unhandled/expected exception, failed asserts, and expected exceptions. If you debug, the same happens except, CRAZY SURPRISE AHEAD!!!, you can step through it. Also, you can run multiple tests by selecting however many you want and running them.

There are some useful options in the test view. If you right click the column area, you can add columns such as Class Name to help with ordering. After all, you might have a bunch of methods that are named the same in different classes, which sucks. Another thing you can do is left click the down arrow to the right of the refresh button for group by options.

End Note: If you don’t recognize the word “attribute” that’s ok. Most likely you have seen the [Something] notation before if you have used web controls (Possibly winforms controls, no idea). Simply put, attributes are like attaching extra information to just about anything so that later on you can use that information at runtime to perform actions. With the use of reflection, you could, for instance, check for only specific properties on a class that you want to fill dynamically. Say you have a dataset with the “UserName” column and a User class with the property Name. If you wanted to fill that Name property normally you could do something like:


user.Name = dataset["UserName"];


but with relfection you could get the property info, check the properties for a the ones with a certain attribute, and match the value in the attribute to the column name.