I haven’t posted for a while in my irregular series on testing and over the weekend while I was struggling with creating some tests in a personal programming project I discovered an awesome feature of MbUnit.

Early in 2010, we (DotNetNuke Corporation) decided to standardize on MbUnit as our testing framework.  Many of my own projects had been written using MSTest (the framework that ships as part of Visual Studio Team System) and this weekend I decided to port one of my older projects to use this testing framework, as I am planning to do some more work on it. 

In this project I had an abstract base class with two different implementations – something quite common in DotNetNuke (DNN) with our extensive use of the Provider Pattern.  I had written quite a few tests in MSTest and I was frustrated that in order to write tests for both concrete implementations I had to do a lot of Copy/Paste inheritance. 

In the code was a comment – “TODO: I don’t like duplicating this code – there must be a better way”.  I tried using a common Test base class for each of the implementations but then all my Test logic was in a different class from the Test Fixture – which made it harder to determine what the test was actually doing.

Enter MbUnit’s ability to test Interfaces - which essentially allows you to write tests against a base type (either an interface or an abstract base class) and re-run the same tests for every implementation.

Let’s look at how this works.  Rather than create an artificial example, lets look at some core .NET collection classes.  The ArrayList and Hashtable classes both implement the IEnumerable interface. The IEnumerable interface has one method GetEnumerator, and we basically only need to test that this method does not return null (Listing 1)

   1:  [TestFixture]

   2:  public class ArrayListTests

   3:  {

   4:      [Test]

   5:      public void GetEnumerator_Does_Not_Return_Null()

   6:      {

   7:          //Arrange

   8:          var collection = new ArrayList();

   9:   

  10:          //Act and Assert

  11:          Assert.IsNotNull(collection.GetEnumerator());

  12:      }

  13:  }

In order to write the same test for a Hashtable we would need to write a completely different test that instantiates a Hashtable instead of an ArrayList (Listing 2).

   1:  [TestFixture]

   2:  public class HashtableTests

   3:  {

   4:      [Test]

   5:      public void GetEnumerator_Does_Not_Return_Null()

   6:      {

   7:          //Arrange

   8:          var collection = new Hashtable();

   9:   

  10:          //Act and Assert

  11:          Assert.IsNotNull(collection.GetEnumerator());

  12:      }

  13:  }

And this is what triggered my original code comment.  This is not very elegant as I have just copy/pasted a whole bunch of code and it is not trivial to refactor.

Also, what if I wanted to test that the method did not return null regardless of whether the collection had any members.  In MSTest I would have to create a whole new method to test this other scenario – another horrible bit of copy/paste inheritance.

We have already seen in this series that MbUnit has the ability to run multiple tests with different input parameters by using the Row attribute.  MbUnit also has the ability to use a Factory attribute to generate multiple instances of objects that a suite of tests can be run against.  This is how we can handle multiple concrete implementations of interfaces and abstract classes (Listing 3).

   1:  public class IEnumerableTests

   2:  {

   3:      public static IEnumerable GetInstances()

   4:      {

   5:          yield return new ArrayList();

   6:          yield return new ArrayList { 0, 1 };

   7:          yield return new Hashtable();

   8:          yield return new Hashtable { { "a", 0 }, { "b", 1 } };

   9:      }

  10:   

  11:   

  12:      [Factory("GetInstances")]

  13:      public IEnumerable Instance;

  14:   

  15:      [Test]

  16:      public void GetEnumerator_Does_Not_Return_Null()

  17:      {

  18:          Assert.IsNotNull(Instance.GetEnumerator());

  19:      }

  20:  }

This is much better.  We still have a simple, understandable Test method “Get_Enumerator_Does_Not_Return_Null”.  The Instance variable is decorated with a Factory attribute, which specifies the “GetInstances” method as the Factory Provider.  The end result is that the test is run four times – one for each IEnumerable instance created by the “GetInstances” method.  If we decide that we need to test another implementation then we just need to add a couple of statements to the “GetInstances” method.

This example was trivial – there was only one test – but what if you have a complex interface or abstract base class with a large number of tests.  In this situation this Factory attribute reduces the amount of work dramatically.  If there are any implementation specific cases that need to be tested they could still be done the traditional way, but this approach allows us to handle most (if not all) of the shared test cases.

In a previous article in this series of blog posts, I introduced Moq (Mock-you) – the mocking framework we are using in DotNetNuke to generate Mock objects for testing.

In this article I will start to dive deeper into this framework by looking at the unusually named “It” class.

What is “It”?

“It” is a static helper class that provides 4 static methods that allows testers to match a method invocation with an arbitrary value, with a value in a specified range, or even one that matches a given predicate.

The four methods it provides are:

1. Is<TValue>(Expression<Predicate<TValue>>)
2. IsAny<TValue>
3. IsInRange<TValue>(TValue from, TValue to, Range rangeKind)
4. IsRegex(string regex) (+ overloads)

The name of the class, while it appears strange, allows us to write readable tests.

For example, continuing our use of the VocabularyController class, lets look at a test for the AddVocabulary method.  Listing 1 shows the AddVocabulary method.

   1:  Public Function AddVocabulary(ByVal vocabulary As Vocabulary) As Integer _

   2:                          Implements IVocabularyController.AddVocabulary

   3:      'Argument Contract

   4:      Requires.NotNull("vocabulary", vocabulary)

   5:      Requires.PropertyNotNullOrEmpty("vocabulary", "Name", vocabulary.Name)

   6:      Requires.PropertyNotNegative("vocabulary", "ScopeTypeId", vocabulary.ScopeTypeId)

   7:   

   8:      vocabulary.VocabularyId = _DataService.AddVocabulary(vocabulary, _

   9:                                      UserController.GetCurrentUserInfo.UserID)

  10:   

  11:      'Refresh Cache

  12:      DataCache.RemoveCache(_CacheKey)

  13:   

  14:      Return vocabulary.VocabularyId

  15:  End Function

As in the previous article, one of the tests we need to write is a test that confirms that the VocabularyId property of the vocabulary is set to the value returned from the call to the DataService (line 8).

   1:  [Test]

   2:  public void VocabularyController_AddVocabulary_Sets_ValidId_On_Valid_Vocabulary()

   3:  {

   4:      //Arrange

   5:      Mock<IDataService> mockDataService = new Mock<IDataService>();

   6:      mockDataService.Setup(ds => ds.AddVocabulary(It.IsAny<Vocabulary>(), It.IsAny<int>()))

   7:                    .Returns(Constants.VOCABULARY_AddVocabularyId);

   8:   

   9:      VocabularyController vocabularyController = new VocabularyController(mockDataService.Object);

  10:   

  11:      Vocabulary vocabulary = ContentTestHelper.CreateValidVocabulary();

  12:   

  13:      //Act

  14:      vocabularyController.AddVocabulary(vocabulary);

  15:   

  16:      //Assert

  17:      Assert.AreEqual<int>(Constants.VOCABULARY_AddVocabularyId, vocabulary.VocabularyId);

  18:  }

In this example we make use of the “It” class in the Setup method of the Mock.  This code is pretty self-explanatory.  In the set up, as long as the mock DataService’s AddVocabulary method is given any Vocabulary instance (It.IsAny<Vocabulary>()) and any integer (It.IsAny<int>()) it should return a known VocabularyId (Constants.VOCABULARY.AddVocabularyId).

The beauty of this class is it is clear what the methods are being used for.

It.IsAny<IFoo>() – means accept any instance of IFoo

It.Is<int>(i => i%2 == 0) – means accept any even number (or any integer which is divisible by 2)

For example:

// given any value return true
mock.Setup(foo => foo.Execute(It.IsAny<string>())).Returns(true);


// given any even number return true
mock.Setup(foo => foo.Add(It.Is<int>(i => i % 2 == 0))).Returns(true); 


// If the value is between 1 and 10 return true
mock.Setup(foo => foo.Add(It.IsInRange<int>(0, 10, Range.Inclusive))).Returns(true); 


// If the string matches the Regex [a-d]+, return "foo"
mock.Setup(x => x.Execute(It.IsRegex("[a-d]+", RegexOptions.IgnoreCase))).Returns("foo");

We can also use it in the Assert phase to verify that a method was called with a particular value..

// assert Execute was called - with any string
mock.Verify(foo => foo.Execute(It.IsAny<string>()));


// assert Add was called with an even number
mock.Verify(foo => foo.Add(It.Is<int>(i => i % 2 == 0))); 


// assert Add was called with a value between 1 and 10 return
mock.Verify(foo => foo.Add(It.IsInRange<int>(0, 10, Range.Inclusive))); 

The “It” class provides readable matching conditions and is an important part of the Moq framework.  In the next part of this series I will continue to dive deeper into this awesome mocking framework.

In a previous article in this series of blog posts, I described the different Test Doubles that can be used when unit testing your application.

My favourite type of Test Double is a Mock.  Mocks are usually dynamically created by a mocking framework. Mock objects are preprogrammed with expectations which form a specification of the calls they are expected to receive.

In DotNetNuke (DNN) we use Moq (pronounced Mock-you).  To quote the creators of Moq - “Moq is designed to be a very practical, unobtrusive and straight-forward way to quickly setup dependencies for your tests. Its API design helps even novice users to fall in the "pit of success" and avoid most common misuses/abuses of mocking.”

Mocking an object that implements an interface (or class) requires less work than any of the other types of Test Double.  In fact in some cases all you have to is create the Mock and then assert that something happened.  Lets look at a real example from the unit tests created to test the new Taxonomy features in DNN 5.3.

We are going to write a test to test the code in Listing 1, the DeleteVocabulary method of the VocabularyController.

   1:  Public Sub DeleteVocabulary(ByVal vocabulary As Vocabulary) _

   2:                                  Implements IVocabularyController.DeleteVocabulary

   3:      'Argument Contract

   4:      Requires.NotNull("vocabulary", vocabulary)

   5:      Requires.PropertyNotNegative("vocabulary", "VocabularyId", vocabulary.VocabularyId)

   6:   

   7:      _DataService.DeleteVocabulary(vocabulary)

   8:   

   9:      'Refresh Cache

  10:      DataCache.RemoveCache(_CacheKey)

  11:  End Sub

The test we are going to write is to confirm that if the method is passed valid arguments, the method will call the DeleteVocabulary method of the DataService.

All we have to do is confirm that the DataService method is called.  We are not testing the DataService here so we don’t care what it does – just that the VocabularyController calls the DataService (Listing 2)

   1:  [Test]

   2:  public void VocabularyController_DeleteVocabulary_Calls_DataService()

   3:  {

   4:      //Arrange

   5:      Mock<IDataService> mockDataService = new Mock<IDataService>();

   6:      VocabularyController vocabularyController = new VocabularyController(mockDataService.Object);

   7:   

   8:      Vocabulary vocabulary = ContentTestHelper.CreateValidVocabulary();

   9:      vocabulary.VocabularyId = Constants.VOCABULARY_ValidVocabularyId;

  10:   

  11:      //Act

  12:      vocabularyController.DeleteVocabulary(vocabulary);

  13:   

  14:      //Assert

  15:      mockDataService.Verify(ds => ds.DeleteVocabulary(vocabulary));

  16:  }

If we review this code we will see that it is set out using the AAA pattern.  We start off by creating a new Mock<IDataService> object that implements the IDataService interface (line 5).  We then create the VocabularyController object, giving it the mocked object (line 6).  Finally, the last part of the “Arrange” phase of the test is to create a valid Vocabulary instance (lines 8 and 9).

We are now ready to test the DeleteVocabulary method of the VocabularyController, which we do in the “Act” phase (line 12).

Finally we assert (or verify) our expectations – that the DeleteVocabulary method of the DataService was called (line 13).

Moq uses a lot of the new features introduced in C# 3 (and VB 9) and .NET 3.5 – especially the use of lambda expressions, and we will see statements like line 15 a lot when we use Moq.

Note the elegant simplicity of this code.  All we had to do was create the Mock<IDataService> object and then use it to verify that one of its methods was called.

So far so good.  This technique works really well when the Interface does not need to return any data – ie in Delete or Update scenarios.  But what about scenarios where the mocked object would be expected to return something, such as in Add or Get scenarios.

Lets first look at the GetVocabularies method in the same VocabularyController class (Listing 3)

   1:  Public Function GetVocabularies() As IQueryable(Of Vocabulary) _

   2:                          Implements IVocabularyController.GetVocabularies

   3:      Return CBO.GetCachedObject(Of IQueryable(Of Vocabulary)) _

   4:                          (New CacheItemArgs(_CacheKey, _CacheTimeOut), _

   5:                                      AddressOf GetVocabulariesCallBack)

   6:  End Function

   7:   

   8:  Private Function GetVocabulariesCallBack(ByVal cacheItemArgs As CacheItemArgs) As Object

   9:      Return CBO.FillQueryable(Of Vocabulary)(_DataService.GetVocabularies())

  10:  End Function

In this case the DataService’s GetVocabularies method is called to retrieve a DataReader from the database and pass it to the CBO class to fill an IQueryable collection which is returned by the GetVocabularies method.

We could just write a test similar to the test in Listing 2, which tests that the DataService’s GetVocabularies method is called (and we do in the test project).  However, we also should test that the if the DataReader returns x records then the VocabulryController returns an IQueryable of x Vocabularies.

   1:  [Test]

   2:  public void VocabularyController_GetVocabularies_Returns_List_Of_Vocabularies()

   3:  {

   4:      //Arrange

   5:      Mock<IDataService> mockDataService = new Mock<IDataService>();

   6:      mockDataService.Setup(ds => ds.GetVocabularies())

   7:              .Returns(MockHelper.CreateValidVocabulariesReader(Constants.VOCABULARY_ValidCount));

   8:      VocabularyController vocabularyController = new VocabularyController(mockDataService.Object);

   9:   

  10:      //Act

  11:      IQueryable<Vocabulary> vocabularys = vocabularyController.GetVocabularies();

  12:   

  13:      //Assert

  14:      Assert.AreEqual<int>(Constants.VOCABULARY_ValidCount, vocabularys.Count());

  15:  }

So just as an in the first test, we create a Mock DataService in line 5.  The major difference is that in lines 6-7 we set up the Mock object to return a valid DataReader.  Moq uses a fluent interface.  The Setup method tells the Mock object which method we are setting up, using our now familiar Lambda expression (ds => ds.GetVocabularies()), and the Returns method tells the Mock object to return the provided object (in this case a valid DataReader with a known count of records).

In line 11, in the “Act” phase we execute the GetVocabularies method to fetch the IQueryable collection, and finally in line 14 we test that the expected number of records was returned.

The main advantage of Mocks is that we only have to implement the method(s) we need to execute the test(s), where as for most other Test Double types we at least have to stub out the implementation.

In future blogs I will show more advanced uses of Moq to enable quite complex tests to be written.