Introduction to Mocking

• Download source - 515.79 KB

Introduction

Mocking is an integral part of unit testing. Although you can run your unit tests without use of mocking but it will drastically slow down the executing time of unit tests and also will be dependent on external resources. In this article we will explain mocking and different benefits that we can achieve by introducing mocking in our unit tests.

Real World Example

We will focus on a real world example so that you will get a good grasp of mocking. Let’s say we are working on banking software which pulls out the customer balance information from some database. The software also makes a request to an external web service for authentication. The process of authentication is slow since it involves many different steps including discovering the web service, serializing the input and output parameters etc.

We want to test that if the customer balance returned is correct or not.

Here is our web service with the Authenticate method:

public class AverageJoeBankService : IAverageJoeBankService
    {
        public bool Authenticate(string userName, string password)
        {
            // This is just simulate the time taken for the web service to authenticate! 
            System.Threading.Thread.Sleep(5000); 
            return true; 
        }     
    }

As you can see, we are simply simulating the Authenticate method. We are assuming that it will take at least 5 seconds to authenticate the user. Of course in real application your Authenticate method will communicate with the real web service.

And here is the AccountBalanceService method:

public class AccountBalanceService
    {
        private IAverageJoeBankService _averageJoeService;

        public AccountBalanceService(IAverageJoeBankService averageJoeService)
        {
            _averageJoeService = averageJoeService;
        }

        public double GetAccountBalanceByUser(User user)
        {       
            // the authenticate method below takes too much time! 
            bool isAuthenticated = _averageJoeService.Authenticate(user.UserName,
                user.Password);

            if (!isAuthenticated)
                throw new SecurityException("User is not authenticated"); 
            
            // access database using username and get the balance 

            return 100;      
        }
    }

Here is our first attempt to write the unit tests:

[Test]
public void should_be_able_to_get_the_balance_successfully_without_using_mock_objects()
{
    User user = new User();
    user.UserName = "johndoe";
    user.Password = "johnpassword";

    _accountBalanceService = new AccountBalanceService(new AverageJoeBankService());

    Assert.AreEqual(100, _accountBalanceService.GetAccountBalanceByUser(user));
}

In the unit test above we are simply using the concrete implementation of the AccountBalanceService class which triggers the actual method for authentication.

When you run your tests you will get the following result:

The test passed and you have a big smile on your face. Not so fast joy boy! Take a look at the time it took to run the test 6.69 seconds. This is too much time to run a single test. Apart from time there are other problems with the test. The test is dependent on the AverageJoeBankService. If the web service is not available then the test will fail. Unit tests should be independent and they should run fast. Let’s make this test faster by introducing mock objects.

Oh wait! We haven’t explained what mock objects mean in the context of unit tests. Mock objects are like real objects but they don’t do anything. We know the definition we just gave you is kind of crazy but you will know what we are talking about in a minute.

Here is the unit test which uses mock objects:

private AccountBalanceService _accountBalanceService;
private MockRepository _mocks;

[SetUp]
        public void initialize()
        {
            _mocks = new MockRepository();            
        }

[Test]
        public void should_be_able_to_get_the_balance_successfully() 
        {
            User user = new User();
            user.UserName = "JohnDoe";
            user.Password = "JohnPassword";

            var averageJoeService = _mocks.DynamicMock<IAverageJoeBankService>();

            _accountBalanceService = new AccountBalanceService(averageJoeService);

            using (_mocks.Record())
            {
                SetupResult.For(averageJoeService.Authenticate(null,
                    null)).IgnoreArguments().Return(true); 

            }

            using (_mocks.Playback())
            {
                Assert.AreEqual(100,_accountBalanceService.GetAccountBalanceByUser(user)); 
            }          
        }

First, we created the MockRepository which is part of the Rhino Mocks frameworks. You might say “What the hell is Rhino Mocks?” Rhino mock is a mocking framework which provides you different mocking features and ways to mock your objects. There are several other mocking frameworks which include NMock, NMock2, TypeMock, MoQ.

Anyway, in the unit test above we are creating a mock object using the following code:

var averageJoeService = _mocks.DynamicMock<IAverageJoeBankService>();
_accountBalanceService = new AccountBalanceService(averageJoeService);

After passing the mocked AverageJoeService (not the real service) to the AccountBalanceService we put our expectations.

using (_mocks.Record())
    {
        SetupResult.For(averageJoeService.Authenticate(null,
            null)).IgnoreArguments().Return(true); 

    }

This means that when the averageJoeService.Authenticate method is fired then returns true so I can proceed further. You can also see that we are not concerned about the passed in arguments and that’s why we are using IgnoreArguments.

The next part is the Playback which is the code that will trigger the expectations and produce the desired result. Here is the Playback part:

using (_mocks.Playback())
    {
        Assert.AreEqual(100,_accountBalanceService.GetAccountBalanceByUser(user)); 
    }

Here is the output of the unit test:

As you can see, now the unit test only takes 1.81 seconds. Not only is the test faster but now it is not dependent on the AverageJoeBankService. This means that even if the web service is down you will be able to run the above test.

Conclusion

In this article we introduced the concepts behind Mocking. Mocking helps to improve unit tests by removing the outside dependencies which results in better, faster, independent unit tests.

We hope you liked the article, happy programming!

NOTE: We have also created a screencast on this subject which you can view using the following link: Screencast: Introduction to Mocking