Unit Tests

On Testing Builder Objects

mhildreth — Sat, 07 Jun 2008 13:00:15 GMT

One of the common scenarios I find myself in is needing to be be able to mock an object instantiated during the lifecycle of another object. For example, a service object might need to, on receiving one message, create an entity, and on receiving another message, call some method on that entity. The easy way to do this is to make a builder as a service for the object needing construction, and mock out the builder object to return a mock. So, for that service-layer code I'm trying to test...

   1:  public class MyService

   2:  {

   3:      private readonly MyBuilder builder;

   4:      private readonly MyEntity entity;

5:

   6:      public MyService(MyBuilder builder)

   7:      {

   8:          this.builder = builder;

   9:      }

10:

  11:      public void OnSomeMessage(Message1 message)

  12:      {

  13:          entity = builder.Build();

  14:      }

15:

  16:      public void OnSomeOtherMessage(Message2 message)

  17:      {

  18:          entity.DoSomething();

  19:      }

  20:  }

Of course, this class is highly stripped down. There should be some error handling if, for example, Message2 is passed first (entity will be null in that case).

I can mock out my entity in the OnSomeOtherMessage method by passing in a mock MyBuilder object to return my mocked entity. When I need to eventually create the implementation for the MyBuilder object, it will look something like this...

   1:  public class MyBuilder

   2:  {

   3:      public MyEntity Build()

   4:      {

   5:          return new MyEntity();

   6:      }

   7:  }

This is fine, although you really can't test MyBuilder. However, even though I see myself as a TDD enthusiast, I don't think I need to test this MyBuilder class. Even if the constructor had args, I feel fine just leaving this as it is without tests. But now, assume that my entity is getting a bit more complex, and that there is a new rule that whenever this object is created, a message is sent out. This message should contain information that the entity holds, but the logic is too complex to do in the constructor. I've decided that an Initialize() method must be put on the MyEntity object. So, where do I call that Initialize method?

My gut reaction would be, in the builder. However, now because my builder has a bit of logic in it, I'm going to want to be able to test that builder to make sure that after it creates an entity, it calls this Initialize() method on it before returning. But, I run into that same problem of how do I mock the MyEntity object. Last time I ran into this problem, I added a builder, so let's do that...

   1:  public class MyBuilder

   2:  {

   3:      private readonly NoReallyThisIsTheBuilder builder;

4:

   5:      public MyBuilder(NoReallyThisIsTheBuilder builder)

   6:      {

   7:          this.builder = builder;

   8:      }

9:

  10:      public MyEntity Build()

  11:      {

  12:          var entity = builder.Build();

  13:          entity.Initialize();

14:

  15:          return entity;

  16:      }

  17:  }

Ok, this is just getting silly. I'm not going to really create another builder object. I felt dirty enough creating the first builder, I'd hate to just keep making turtles all the way down.

This situation is easily solved with TypeMock

   1:  [Test]

   2:  public void TestObjectInstantiation()

   3:  {

   4:      MockManager.Init();

5:

   6:      var theMock = MockManager.Mock(typeof(Entity), Constructor.StaticNotMocked);

7:

   8:      theMock.ExpectConstructor(1);

   9:      theMock.ExpectCall("Initialize", 1);

10:

  11:      var builder = new Builder();

  12:      var results = builder.Build();

13:

  14:      Assert.That(results, Is.EqualTo(theMock.MockedInstance));

15:

  16:      MockManager.Verify();

  17:  }

But I'm not going to use a whole new framework just to support one style of test. If I used TypeMock more often, I'd probably go with this, but since I don't, I won't. Instead, I'll go with making a test-specific subclass...

   1:  public class Builder

   2:  {

   3:      protected virtual Entity BuildNewEntity()

   4:      {

   5:          return new Entity();

   6:      }

7:

   8:      public Entity Build()

   9:      {

  10:          var entity = BuildNewEntity();

  11:          entity.Initialize();

12:

  13:          return entity;

  14:      }

  15:  }

16:

  17:  public class TestSpecificBuilder : Builder

  18:  {

  19:      private Entity entity;

20:

  21:      public void SetStartingEntity(Entity startingEntity)

  22:      {

  23:          if (startingEntity == null) throw new ArgumentNullException("startingEntity");

24:

  25:          entity = startingEntity;

  26:      }

27:

  28:      protected override Entity BuildNewEntity()

  29:      {

  30:          return entity;

  31:      }

  32:  }

Slightly off-topic, but here's my take on TypeMock, which has been the center of controversy in the ALT.NET spectrum. Here's one situation where I find it helpful. The problem is, there isn't many other situations where I say that, and using a test-specific subclass is fine by me.That isn't to say there isn't any situations where you might use it. If you are doing a project with more lower-level code that is very close to the .NET framework in all it's sealed goodness, or perhaps working with legacy code, it would probably be more useful, but so far in my travels I haven't found many situations where it was miles beyond just using proper object relations.

In fact, the same probably goes for most mocking frameworks. I use them to mock objects, not create test seams. Most of my objects have only one or two methods on them, so writing a hand-written mock is pretty simple, and makes the tests easier to read ("EntityWasInitializedOnce" vs. "Expect.Call(entity.Initialized()).Times(1)"). I find my test seams mostly create themselves (with the above being one of the few examples where they don't). But remember, my experience with TypeMock goes as far as me downloading it this morning and creating that test I wrote above, so use your own judgement.

Developing made easier through Equals overriding.

mhildreth — Thu, 24 Apr 2008 03:01:53 GMT

I often have found that working with small, immutable objects can be very helpful. First off, they are extremely easy to test, typically not needing any sort of mocking involved. Second, due to their immutable state, you can easily override Equals to use to your advantage. The advantage I'll talk about today is the ability to introduce a new test seam that doesn't depend upon inversion of control to be able to test an object.

Suppose I'm writing an object that will represent a query. The query should return all blogs that contain certain text in their titles...

public class BlogWithTextInTitle : Query<Blog, BlogCollection>
{
    private string text;

    public BlogWithTextInTitle(string text)
    {
        this.text = text.ToLower();
    }

    public BlogCollection RunOn(IQueryable<Blog> queryable)
    {
        var results = from b in queryable
              where b.Title.ToLower().Contains(text)
              select b;
        return new BlogCollection(results.ToArray());
    }
}

Fun stuff! Now, suppose that I am going to write something in my service layer that will query all the blogs with the text "Hello World" in the title, and send a warning to their owner about how unimaginative their blog titles are.

(Stupid examples. I'm full of 'em.)

Now, you'll notice this query implements an interface, Query. My repository will have something like a "Find" or "RunQuery" method on it to run these queries (check out Ayende's post "Thinking about repositories" for more details on this). The service might look like this...

public class SendWarningService : ISendWarningService
{
    private Repository repository;

    public SendWarningService(Repository repository)
    {
        this.repository = repository;
    }

    public void SendWarningToThoseWithTextInTitle(string text, string warningMessage)
    {
        var query = null; // How do I create the query, while still being able to use it in a test?
            
        BlogCollection blogs = repository.FindAll(query);
        blogs.SendWarningToAll(warningMessage);
    }
}

I need to test that the blog collection returned has it's SendWarningToAll method called, but how can I control what FindAll returns? Typically, I would use a stub, but I would need to create that stub in the test method. How could I then pass that stub to the actual method? I could put a QueryFactory into the constructor, and then mock out the factory to have it return my stub, but I don't like that idea. Interestingly, we don't seem to have this problem with value types, do we? Let's assume that the query were a value type (which, I guess if you really wanted to, you could do by making it a struct, but I don't think I'm comfortable with that). Here's what the test would look like...

   1:  public void GivesWarningToBloggersReturnedFromQuery()

   2:  {

   3:      // Create test values.

   4:      var text = "Hello World";

   5:      var warningMessage = "Hello World? 'cmon, it's been done before!";

6:

   7:      var expectedQuery = new BlogWithTextInTitle(text); // Check it out, I'll just go ahead and create this thing...

8:

   9:      var repository = new FakeRepository();

  10:      var blogCollection = new FakeBlogCollection();

11:

  12:      // Set the repository to reutrn the fake blog collection when it recieves the query object.

  13:      repository.SetupResultFor(expectedQuery).Return(blogCollection);

14:

  15:      // Exercise the test.

  16:      var service = new WarningBlogsService(repository);

  17:      service.SendWarningToAllWithTitleContaining(text);

18:

  19:      // Check that the collection had it's message sent.

  20:      Assert.That(blogCollection.MessageWasSent(warningMessage), "Message was not sent.");

  21:  }

Notice that at no time am I ever passing the query object (expectedQuery) into the service. Instead, the service will be allowed to make another query object, simply using the new operator.

   1:  public class SendWarningService : ISendWarningService

   2:  {

   3:      private IRepository repository;

4:

   5:      public SendWarningService(IRepository repository)

   6:      {

   7:          this.repository = repository;

   8:      }

9:

  10:      public void SendWarningToThoseWithTextInTitle(string text, string warningMessage)

  11:      {

  12:          var query = new BlogWithTextInTitle(text);

13:

  14:          BlogCollection blogs = repository.FindAll(query);

  15:          blogs.SendWarningToAll(warningMessage);

  16:      }

  17:  }

See on line 12, I just go ahead and create the object. However, if I ran the test as it is, it would fail, because right now my fake repository (and any mock framework you use) will probably be doing the default testing of equality by reference. Obviously, the object created in my test is not equal to the one created in the actual method, because they do not reference the same object. However, by overriding Equals on our query, we can actually make this work...

public class BlogWithTextInTitle : Query<Blog, BlogCollection> {
    private string text;

    public BlogWithTextInTitle(string text)
    {
        this.text = text.ToLower();
    }

    public BlogCollection RunOn(IQueryable<Blog> queryable)
    {
        var results = from b in queryable
              where b.Title.ToLower().Contains(text)
              select b;
        return new BlogCollection(results.ToArray());
    }

    public override bool Equals(object obj)
    {
        var other = obj as BlogWithTextInTitle;
        if (ReferenceEquals(null, other)) return false;

        return text.Equals(other.text);
    }

    public override int GetHashCode()
    {
        return text.GetHashCode();
    }
}

This is sort of like using a whole new test seam. Typical test seams used are the constructors, properties, and method parameters, which are all used to pass mocks and stubs. The problem is that you can start filling these up quickly. By using value equality to your advantage, you can "pass" a stub into your system under test without using another parameter.

Now I've been bitten before by screwing up such a repetitive thing like overriding Equals. Furthermore, Testing that you've overridden Equals correctly could include a bunch of tests...

Not equal to null
Not equal to an object of a different type.
Not equal to an object of the same type with different parameters.
Equal to an object of the same type with same parameters.

That's four tests to test three lines of code (I don't test GetHashCode()... technically you could just return 0 and things would still work, just with a performance hit, but do read the comments below!). And, I've found that I do this a lot. For example, testing that you threw a custom assertion correctly is much easier when all you need to do is create the assertion yourself and check that this assertion equals the one just thrown.

So, eventually, I started needing to do these kind of tests enough that I created my own class for it. Basically, the test will test that a class adheres to the idea of Constructor Equality. This means that two objects will be considered equal if they were created by using the same constructor parameters.

   1:  public class ConstructorEqualityTest<T>

   2:  {

   3:      private readonly T same1;

   4:      private readonly T same2;

   5:      private readonly T[] different;

6:

   7:      public ConstructorEqualityTest(T same1, T same2, params T[] different)

   8:      {

   9:          this.same1 = same1;

  10:          this.same2 = same2;

  11:          this.different = different;

  12:      }

13:

  14:      public IList<string> Failures

  15:      {

  16:          get

  17:          {

  18:              IList<string> failures = new List<string>();

19:

  20:              if (!PassesEqualToNullTest())

  21:              {

  22:                  failures.Add("Type should not be equal to null.");

  23:              }

24:

  25:              if (!PassesEqualToOtherTypeTest())

  26:              {

  27:                  failures.Add("Type should not be equal to a different type.");

  28:              }

29:

  30:              if (!PassesEqualToSameConstructorArgs())

  31:              {

  32:                  failures.Add("Type should be equal to another type constructed with the same arguments.");

  33:              }

34:

  35:              foreach (int indexMarkedAsSame in GetDifferentObjectsMarkedAsSame())

  36:              {

  37:                  failures.Add("Type should not be equal to another type constructed with different arguments (Different Argument " + indexMarkedAsSame + " was seen as same)");

  38:              }

39:

  40:              return failures;

  41:          }

  42:      }

43:

  44:      public string FailureMessage

  45:      {

  46:          get

  47:          {

  48:              StringBuilder stringBuilder = new StringBuilder();

  49:              stringBuilder.AppendLine("The object did not pass all requirements for Constructor Equality.");

50:

  51:              foreach (string failureMessage in Failures)

  52:              {

  53:                  stringBuilder.AppendLine(failureMessage);

  54:              }

55:

  56:              return stringBuilder.ToString();

  57:          }

  58:      }

59:

  60:      private bool PassesEqualToSameConstructorArgs()

  61:      {

  62:          return same1.Equals(same2);

  63:      }

64:

  65:      private bool PassesEqualToNullTest()

  66:      {

  67:          return !same1.Equals(null);

  68:      }

69:

  70:      private bool PassesEqualToOtherTypeTest()

  71:      {

  72:          return !same1.Equals("A_String");

  73:      }

74:

  75:      private IList<int> GetDifferentObjectsMarkedAsSame()

  76:      {

  77:          IList<int> list = new List<int>();

  78:          for (int index = 0; index < different.Length; index++)

  79:          {

  80:              if (same1.Equals(different[index]))

  81:              {

  82:                  list.Add(index);

  83:              }

  84:          }

85:

  86:          return list;

  87:      }

88:

  89:      private bool PassesEqualToDifferentConstructorArgs()

  90:      {

  91:          return GetDifferentObjectsMarkedAsSame().Count == 0;

  92:      }

93:

  94:      public bool Passes()

  95:      {

  96:          return PassesEqualToNullTest() &&

  97:              PassesEqualToOtherTypeTest() &&

  98:              PassesEqualToDifferentConstructorArgs() &&

  99:              PassesEqualToSameConstructorArgs();

 100:      }

 101:  }

So now, if I wanted to test that my query works adheres to the concept of "Constructor Equality", I could use this test...

[Test]
public void AdheresToConstructorEquality()
{
    var same = new BlogWithTextInTitle("same");
    var same2 = new BlogWithTextInTitle("same");
    var different = new BlogWithTextInTitle("different");

    var test = new ConstructorEqualityTest<BlogWithTextInTitle>(same, same2, different);

    Assert.That(test.Passes(), test.FailureMessage);
}

First, I created two objects that should be equal. I'll also created additional different objects that will all be tested to ensure that Equals will return false. Each one should be different from the "same" objects from one parameter. If I had a class that had two parameters, I would use the following...

[Test]
public void AdheresToConstructorEquality()
{
    var same = new MyClassToTest(1 ,2);
    var same2 = new MyClassToTest(1, 2);
    var different1 = new MyClassToTest(-999, 2);
    var different2 = new MyClassToTest(1, -999);

    var test = new ConstructorEqualityTest<MyClassToTest>(same, same2, different1, different2);

    Assert.That(test.Passes(), test.FailureMessage);
}

My test will fail to begin with, with the failure message telling me that the objects created with the same arguments should be equal, but they aren't. Then I would override equals until my test passes.

Beyond ExpectedException

mhildreth — Thu, 17 Apr 2008 11:09:30 GMT

Note: For users of NUnit, version 2.5 will have an Assert.Throws method. This version is currently available in alpha status.

On the ALT.NET mailing list, there was a discussion about using the [ExpectedException] attribute in NUnit. Most people have come to figure out that using the ExpectedException attribute on your tests has disadvantages. First, your test will not be able to pinpoint exactly where the exception is supposed to occur. You could get false negatives for having the exception thrown in the wrong method. As an example, imagine you are testing that an ArgumentNullException is thrown when you call a method:

[Test]
[ExpectedException(typeof(ArgumentNullException))]
public void ErrorWhenTryingToAddNullMonkey()
{
   ILogger logger = BuildStubLogger();
   MonkeyCage monkeyCage = new MonkeyCage(logger);

   monkeyCage.AddMonkey(null);
}

In this example, you're trying to test that the ArgumentNullException gets thrown because we're trying to add a null Monkey. However, this test might pass if we accidentally made BuildStubLogger() return null, and our constructor is the code throwing the ArgumentNullException for the null logger.

Second, you cannot be sure that the correct arguments were passed to the exception. Let's assume that you fixed your problem above with BuildStubLogger(), and the ArgumentNullException is thrown from AddMonkey. Maybe you want to test to make sure that the ArgumentNullException was thrown with the correct paramName argument. There's no way of doing this with the ExpectedException attribute. Knowing this, you may start creating tests like this...

1:

   1:  [Test]

   2:  public void ErrorWhenTryingToAddNullMonkey()

   3:  {

   4:     ILogger logger = BuildStubLogger();

   5:     MonkeyCage monkeyCage = new MonkeyCage(logger);

6:

   7:     try

   8:     {

   9:        monkeyCage.AddMonkey(null);

  10:        Assert.Fail("Exception never thrown.");

  11:     }

  12:     catch (ArgumentNullException ex)

  13:     {

  14:        Assert.That(ex.ParamName, Is.EqualTo("monkey"), "Exception thrown, but has incorrect param name.");

  15:     }

  16:  }

Our try block will catch the exception (and the test will fail if any other exception is thrown). Also, on line 10, we have an Assert.Fail to ensure that if the exception is not thrown, that the test fails. The problem here is pretty obvious: it's a lot of code for such a simple idea. After writing this multiple times, you could very easily start missing key parts, most notably being forgetting that Assert.Fail() call.

xUnit, the newest test framework on the block, has a nice way of dealing with this, using an Assert.Throws method that allows you to specify where the exception should be thrown and what the exception should look like. However, I'm not going to switch testing frameworks just for this. And, it's pretty simple to write your own. Here's what the results could look like...

public static class AssertThrows<T>
        where T : Exception
    {
        public delegate void NormalCode();
        public delegate void AssertionCode(T exception);
        
        public static void For(NormalCode normalCode)
        {
            For(normalCode, delegate { });
        }

        public static void For(NormalCode normalCode, AssertionCode assertionCode)
        {
            bool expectionThrown = false;
            
            try
            {
                normalCode.Invoke();
            }
            catch (T ex)
            {
                assertionCode.Invoke(ex);
                expectionThrown = true;
            }

            if (!expectionThrown) throw new ExceptionNeverThrownException(typeof(T));
        }
    }

Here's how you would use it...

[Test]
public void ErrorWhenTryingToAddNullMonkey()
{
   ILogger logger = BuildStubLogger();
   MonkeyCage monkeyCage = new MonkeyCage(logger);

   AssertThrows<ArgumentNullException>.For(
      delegate { 
         monkeyCage.AddMonkey(null);
      },
      delegate (ArgumentNullException ex) {
         Assert.That(ex.ParamName, Is.EqualTo("monkey"));
      });
}

You can do whatever tricks you want to clean it up, but on .NET 2.0, this is ok for me. Since I'm moving over to .NET 3.5, the delegates will soon become lambda's.