Tag Archives: unit testing

Ordered Tests with Rhino Mocks AAA Syntax

Before the AAA syntax was introduced, you would create ordered unit tests by wrapping Expect calls in a using block like so:

var mocks = new MockRepository();
using (mocks.Ordered())
{
    // ...
}

However, AAA syntax does not require you to instantiate a MockRepository, so how can we do ordered tests? This can be accomplished by accessing the implied MockRepository via the GetMockRepository method.

var myMock = MockRepository.GenerateMock<IMyInterface>();
using (myMock.GetMockRepository().Ordered())
{
    // ...
}

Here’s a complete example.

[TestMethod]
public void RunTest()
{
    // Arrange
    var target = new Program();
    var mockModel = MockRepository.GeneratePartialMock<MyModel>();
    target.Model = mockModel;

    using (mockModel.GetMockRepository().Ordered())
    {
        mockModel.Expect(x => x.Populate());
        mockModel.Expect(x => x.Save());
    }

    // Act
    target.Run();

    // Assert
    mockModel.VerifyAllExpectations();
}
// This fails
public void Run()
{
    Model.Save();
    Model.Populate();
}

// This passes
public void Run()
{
    Model.Populate();
    Model.Save();
}

Unit Testing Stored Procedure Calls with Rhino Mocks

Database stored procedure calls are one of the trickiest things to unit test, and there are many different approaches that can be taken. My team has run the gamut: test DBs that rollback with each run, no testing for direct data access functions (!), virtual functions w/ partial mocks (see here).

The latest approach that I’ve been using is much more straightforward and feels like a more natural use of Rhino Mocks. Let’s look at some examples of how to test some common database stored procedure tasks. (Note that these examples assume use of the Microsoft Enterprise Library.)

Create a mockable Database

The primary challenge that I’ve found with testing database code is that Microsoft.Practices.EnterpriseLibrary.Data.Database isn’t mock-friendly. However, the other “pieces” such as DbCommand and DbCommandParameterCollection are very easy to work with. So, we can solve the Database problem by creating a simple wrapper (Important! Note that the methods have the virtual keyword, which will allow them to be overridden.):

public class DatabaseWrapper
{
    private Database _database;
    private Database Database
    {
        get { return _database = _database ?? DatabaseFactory.CreateDatabase(); }
        set { _database = value; }
    }

    public virtual DbCommand GetStoredProcCommand(string storedProcedureName)
    {
        return Database.GetStoredProcCommand(storedProcedureName);
    }

    public virtual void DiscoverParameters(DbCommand command)
    {
        Database.DiscoverParameters(command);
    }
}

Executing a stored procedure

Now that we are able to mock the database object, we can write some useful tests. Let’s say you want to execute a stored procedure named “MyStoredProcedure,” and you want to write a test to verify that your code handles an exception thrown when it’s executed. That’s very easy!

Here’s my class with the function I want to test:

public class MyDataAccess
{
    public DatabaseWrapper Database { get; set; }
    public Thingy GetThingy()
    {
        Thingy thingy = null;
        try
        {
            var dbCommand = Database.GetStoredProcCommand("MyStoredProcedure");
            Database.DiscoverParameters(dbCommand);
            var result = dbCommand.ExecuteNonQuery();
            // populate thingy
        }
        catch (Exception ex)
        {
            // handle exception
        }
        return thingy;
    }
}

And here’s my test that will throw an exception when the stored procedure is executed. I create my DatabaseWrapper as a PartialMock, allowing me to override its methods.

[TestMethod]
public void GetThingyHandlesException()
{
    // Arrange
    var target = new MyDataAccess();
    var mockDatabase = MockRepository.GeneratePartialMock<DatabaseWrapper>();
    target.Database = mockDatabase;

    // mock Database
    const string storedProc = "MyStoredProcedure";
    var mockDbCommand = MockRepository.GenerateMock<DbCommand>();
    mockDatabase.Expect(x => x.GetStoredProcCommand(storedProc))
        .Return(mockDbCommand);
    mockDatabase.Expect(x => x.DiscoverParameters(mockDbCommand));
    
    // mock DbCommand
    var ex = new Exception("Oh noes!");
    mockDbCommand.Expect(x => x.ExecuteNonQuery())
        .Throw(ex);

    // Act
    var actual = target.GetThingy();

    // Assert
    mockDatabase.VerifyAllExpectations();
    mockDbCommand.VerifyAllExpectations();
    Assert.IsNull(actual);
}

Setting input parameters

Need to set some input parameters? No problem!

dbCommand.Parameters["@id"].Value = id;

And, in your test, you add this:

var mockParams = MockRepository.GenerateMock<DbParameterCollection>();
var mockParam = MockRepository.GenerateMock<DbParameter>();

mockDbCommand.Expect(x => x.Parameters).Return(mockParams);

mockParams.Expect(x => x["@id"]).Return(mockParam);

const int id = 123;
mockParam.Expect(x => x.Value = id);

mockParams.VerifyAllExpectations();
mockParam.VerifyAllExpectations();

Reading output parameters

How about output parameters?

thingy.Value = dbCommand.Parameters["@Value"].Value as string;

Add the additional mocks and assertions:

var mockOutParam = MockRepository.GenerateMock<DbParameter>();

mockParams.Expect(x => x["@Value"]).Return(mockOutParam);

const string value = "MyValue";
mockOutParam.Expect(x => x.Value).Return(value);

mockParams.VerifyAllExpectations();
mockOutParam.VerifyAllExpectations();
Assert.AreEqual(value, actual.Value);

Working with sets of parameters

When you have more than a few parameters to work with, the unit test code can get quite lengthy. I like to keep it clean by extracting the duplicated logic into a separate function, like so:

var paramsToVerify = new List<DbParameter>();
mockParams.Expect(x => x["@whammyparammy"])
    .Return(MockParameter<int>(paramsToVerify));

My function allows you to specify and verify the type of each parameter, but you could easily modify it to expect a specific value.

private static DbParameter MockParameter<T>(List<DbParameter> paramsCollection)
{
    // set Expect with Arg<T>.Is.TypeOf to force the specific type
    var mockParam = MockRepository.GenerateMock<DbParameter>();
    mockParam.Expect(x => x.Value = Arg<T>.Is.TypeOf);

    if (paramsCollection != null)
        paramsCollection.Add(mockParam);

    return mockParam;
}

I keep the parameters in a list so I can verify them during my assertions.

paramsToVerify.ForEach(x => x.VerifyAllExpectations());

Testing Hard-to-Test Code with Rhino Mocks

One of the most common gripes that I hear about getting started with unit testing is that the code isn’t testable or it doesn’t have a testable design. People will make claims like, “We need X hours to make the project testable before we can start writing tests.” Well, I don’t buy into that. There are techniques that you can employ to extract the pieces of code you’re modifying into little, testable nuggets that have nothing to do with the rest of the not-so-test-friendly project. I’m going to cover two of my favorite, most-commonly used techniques in this post.

Extract the code to be tested.

This is a pretty straightforward solution to a not-so-obvious problem. The most common scenario that I’ve seen for this technique is the “monster function.” I’m sure you’ve seen this before. It’s the 1000-line function that contains all the logic for the module or application you’re modifying. This is a classic hard-to-test situation because, at first glance, it seems like you need to set up everything necessary to complete the entire process in order to do any sort of unit testing.

To transform this mess into an unit testing masterpiece, you just need to do what nobody before you thought of: create a new function. Your new function can do whatever you need it to do. It can accept inputs. It can return outputs. And, it can do it all in a testable manner! So, make your function, test the hell out of it, then call your function from the appropriate place in the main function. Congratulations–you just made a unit tested change to a previously non-testable function.

Extract the code to be avoided.

The second scenario is a little more difficult, and the solution is a little less obvious. I use this technique when I’m dealing with external dependencies that aren’t enough to warrant an entire interface or when I’m working with tricky internal dependencies. Let’s look at an example. Consider the following function:

public class HardToTest
{
    public void ProcessFile()
    {
        string contents;
        using (var fs = new FileStream(@"c:\data.xml", FileMode.Open))
        {
            var sr = new StreamReader(fs);
            contents = sr.ReadToEnd();
        }
        // Do something interesting with file contents
    }
}

When sitting down to write a unit test for this function, you might be tempted to create a “data.xml” file in the root directory of the C drive during TestInitialize. That would probably result in a passing unit test on your machine, but please, don’t do that. You can trust that the FileStream and StreamReader objects will do their jobs correctly, so let’s just take them out of the equation for our unit testing. With a quick refactor, we end up with something like this:

public class HardToTest
{
    public void ProcessFile()
    {
        string contents = GetFileContents();
        // Do something interesting with file contents
    }
    
    internal protected virtual string GetFileContents()
    {
        using (var fs = new FileStream(@"c:\data.xml", FileMode.Open))
        {
            var sr = new StreamReader(fs);
            return sr.ReadToEnd();
        }
    }
}

Ok, great! Now, here’s where it gets fun. We can write a test for this function by mocking just the function we’re trying to avoid. Check it out:

[TestMethod()]
public void ProcessFileTest()
{
    HardToTest target = MockRepository.GeneratePartialMock();
    target.Expect(x => x.GetFileContents()).Return("File contents!");
    target.ProcessFile();
    target.VerifyAllExpectations();
}

Because we made our GetFileContents function virtual, the generated mock class can override its functionality. The Partial Mocks gives us this functionality; if the function were not overridden, it would be called as-is and would try to read from the hard-coded file path.

You could stick with this same approach to handle different scenarios that might arise in the isolated code. For instance, what would happen if the file did not exist? You would expect the isolated code to throw a System.IO.FileNotFoundException, right? Well, let’s test that!

[TestMethod]
[ExpectedException(typeof(System.IO.FileNotFoundException))]
public void ProcessFile_ThrowsFileNotFoundException()
{
    HardToTest target = MockRepository.GeneratePartialMock();
    target.Expect(x => x.GetFileContents()).Throw(
        new System.IO.FileNotFoundException());
    target.ProcessFile();
}

Some additional notes about this solution:

  • The function must be internal (see next note) protected (prevents calling of the function while setting expectation) virtual (allows function to be overridden).
  • The target project must expose its internals to the test project. This can be done by adding the “[assembly: InternalsVisibleTo(“YourTestProjectName”)]” attribute to the target project’s assembly.info file. You can read more about this attribute here.

Getting Started with Rhino Mocks (AAA)

When you’re writing unit tests for your code, you want to write specific tests for specific units. Unfortunately, it is not uncommon for you code to have many external dependencies that may not be related to the functionality that you’re trying to test. This is where one of my very favorite unit testing tools, Rhino Mocks, comes into play.

Rhino Mocks is great because it allows you to mock or stub objects in your code so that you can really focus on the functionality that you’re trying to test without having to worry about doing an excessive amount of setup or external dependencies.

When you’re getting started with Rhino Mocks, one of the most confusing things that you’ll run into is that there are several different syntaxes that can be used to accomplish the same thing. The AAA (Arrange, Act, Assert) syntax is the newest and was introduced with version 3.5. The primary distinction of the AAA syntax is that you don’t need to create and manage a MockRepository object and its various states.

In this article, I will walk you through the task of writing a unit test using Rhino Mocks.

So, before we begin writing our tests, let’s look at the code we’ll be testing.

public class Controller
{
    public IDataSource DataSource { get; set; }

    public int[] Data { get; set; }

    public void Process()
    {
        if (this.DataSource.DataAvailable())
        {
            this.Data = this.DataSource.GetData();
        }
    }
}

We can see that we have a Controller class that utilizes some sort of IDataSource object to check for and retrieve data. When we’re testing our controller class, we may or may not have access to our data source, though. And, even if we do have access to the data source, we may not have complete control over it. So this is an excellent situation to employ Rhino Mocks!

The first step to using Rhino Mocks is simply adding a reference to your project. Once the reference is in place, we can add the using statement to the top of our test class and get to mockin’.

Creating a mock object is extremely simple with Rhino Mocks’s AAA syntax. You just use the static MockRepository class’s GenerateMock function.

var mockDataSource = MockRepository.GenerateMock();

Now that we’ve created our mock object, we need to configure our target object to use it. In this case, our class’s IDataSource is a public property on the class. So configuring the target object is a simple assignment.

Controller target = new Controller();
target.DataSource = mockDataSource;

Okay, great! Our next step is to set the expectations for our mock object. For our first test, we’ll just have the call to DataAvailable return false.

mockDataSource.Expect(x => x.DataAvailable()).Return(false);

The last steps for this test are to run the function we’re testing and verify that our mock object was used as expected.

target.Process();
mockDataSource.VerifyAllExpectations();

When we run this test, the Process function will call our mock object’s DataAvailable function–which we have pre-configured to return false–and the test will pass as long as DataAvailable is called.

We can run this test, and it should pass. Awesome, now let’s write another test. This time, we’ll have DataAvailable return true. We create the mock object the same way as previously, but we’ll need to set the expectations differently.

mockDataSource.Expect(x => x.DataAvailable()).Return(true);
var data = new int[] {1, 2, 3};
mockDataSource.Expect(x => x.GetData()).Return(data);

Since we’re passing some data in, we can also add an extra assertion in our unit test.

mockDataSource.VerifyAllExpectations();
Assert.AreEqual(data, target.Data);

This unit test will fail unless both DataAvailable and GetData are called. Additionally, the target object’s Data property must be the object returned by GetData.

Here is the complete text for the two unit tests we’ve just created.

[TestMethod()]
public void ProcessTest_DataAvailableReturnsFalse()
{
    var mockDataSource = MockRepository.GenerateMock();

    Controller target = new Controller();
    target.DataSource = mockDataSource;

    mockDataSource.Expect(x => x.DataAvailable()).Return(false);

    target.Process();
    mockDataSource.VerifyAllExpectations();
}

[TestMethod()]
public void ProcessTest_DataAvailableReturnsTrue()
{
    var mockDataSource = MockRepository.GenerateMock();

    Controller target = new Controller();
    target.DataSource = mockDataSource;

    mockDataSource.Expect(x => x.DataAvailable()).Return(true);
    var data = new int[] { 1, 2, 3 };
    mockDataSource.Expect(x => x.GetData()).Return(data);

    target.Process();
    mockDataSource.VerifyAllExpectations();
    Assert.AreEqual(data, target.Data);
}

Unit Testing: Hello, World!

The “Hello, World!” of unit tests typically involves a function that accepts inputs and provides an expected output. Consider the following Calculator class:

public class Calculator
{
    public static int Add(int x, int y)
    {
        return x + y;
    }
    public static int Divide(int dividend, int divisor)
    {
        return dividend / divisor;
    }
}

Writing unit tests for the Add method is simple and straightforward. We can declare our inputs, come up with the expected output, execute the function and verify the result.

[TestMethod]
public void AddTest()
{
    int x = 1;
    int y = 2;
    int expected = 3;
    int actual = Calculator.Add(x, y);
    Assert.AreEqual(expected, actual);
}

The Add method is so simple that there isn’t much more you can do with it, so let’s take a look a the Divide method. Similarly to the Add method, we can write a simple unit test to verify our core behavior.

[TestMethod]
public void DivideTest()
{
    int dividend = 10;
    int divisor = 2;
    int expected = 5;
    int actual = Calculator.Divide(dividend, divisor);
    Assert.AreEqual(expected, actual);
}

Now that we have that out of the way, let’s deal with an exception case: division by zero. Before we can test or code, we must decide what we want our application to do in this scenario. I have decided that application should simply throw the default divide-by-zero exception, so let’s write a test for it to help ensure that this functionality isn’t lost with future changes.

[TestMethod]
[ExpectedException(typeof(System.DivideByZeroException))]
public void DivideTest_DivisionByZero()
{
    int dividend = 10;
    int divisor = 0;
    int actual = Calculator.Divide(dividend, divisor);
}

By decorating the test method with the ExpectedException attribute, the test will fail if the exception is not thrown.

You can see that writing unit tests for these something-in-something-out functions can be very easy. Try to test as many different scenarios as you can come up with. Some common situations to consider are minimums, maximums, default values, and nulls. Write skeleton tests up-front to help you remember relevant scenarios to be handled by your code.

Unit Testing Guidelines

There always seems to be a lot of discussion regarding the whens and hows of unit testing. These can be challening topics when you’re getting started with unit testing, and I wanted to document some of the rules, guidelines, and lessons-learned that I apply when writing my own tests.

Keep it simple.

If it seems like testing a piece of functionality is really hard, there’s probably an easier way. One of the keys to writing good unit tests is having testable code. (Duh, right?) Well, one of the best skills that you can have is the ability to take a block of untestable code and transform it into a well-tested masterpiece. Doing this isn’t as hard as it may seem. The secret is identifying the natural seams in the code and extracting them into testable and/or mockable objects and functions. Divide and conquer!

It’s not all or nothing.

Sometimes when you’re working with legacy code that doesn’t have unit tests, it’s easy to follow suit and not write tests yourself. Just because tests don’t exist for existing code doesn’t mean that you can’t write tests for your changes, though. If you write a test to confirm a change that you make, you’re future-proofing your change. If somebody comes along later and messes up your change, your test will fail even if it’s the only test in the whole world.

It’s been said before, but it’s true: one test is better than no tests. It’s also unlikely that you’ll ever go back and unit test everything in a project hat wasn’t tested previously, so just start already!

Test what makes sense.

Code coverage is great, and 100% is a great goal to strive for, but I don’t think it’s realistic in most situations. If you’re writing a test where you’re replicating the entire contents of the function you’re testing to create expectations and asserts of the test, it may be a bad test for two reasons. First, you don’t feel good about the test you’ve written. Second, you’ve made your code more rigid because changing the actual function will require you to make the same change again in the unit test. Blech!

Instead, strive to write tests that you believe are meaningful and useful. A good example of this would be translating a person object. It may not be useful to test that ObjectA.LastName equals ObjectB.LastName and ObjectA.FirstName equals ObjectB.FirstName, but it may be worthwhile to write a test that verifies that ObjectA.SsnAsInteger populates correctly into ObjectB.SsnFormattedString. It’s hard to come up with a good, brief example of this, but what I’m trying to get at is that you shouldn’t spend hours and hours working on tests that you yourself see no value in. Grab a peer and look at it together. Maybe they can help you see the value or come up with a better way to test. Or maybe you’ll both agree that the code in question simply doesn’t need to be tested.

Don’t write random value generators and object populators.

I’ve gone through this phase, and I’ve seen others go through it. I want to save you, though. Don’t do this. I know that it seems like a good idea. This should work for any string of any length, so I’ll just write a function to populate my object with a random string of random length! The problem is that when this test fails randomly 1 out of 50 test runs, you may not be able to re-create the situation. I believe it’s better to write a specific test for your specific situation. If you need to test multiple scenarios, write multiples tests.

One of my least favorite unit testing experiences comes from working with a project whose unit tests were written by a code generator that randomly populated complex source business objects, manipulated them, and then used comparison-via-reflection to verify correctness. The problem is that these tests were nearly impossible to maintain and troubleshoot when they failed.