Mocking And Isolation In Unit Testing

By Vagif Abilov

Introduction

The rapid growth of test frameworks and tools accompanied by books and articles on various aspects of TDD does not only bring solutions to developers’ needs, it also brings confusion. Dummy objects, fakes, stubs, mocks – what should we use? And when? And why? What complicates the situation is that most developers can not afford to invest much time into test methodology studies – their efficiency is usually measured using different criteria, and although the management of modern software projects is well aware of how important is to surround production code with maintainable test environment, they are not easy to convince to dedicate hundreds of working hours into updating system tests due to a paradigm shift.

So we have to try to get things right with minimal effort, make our decisions based on simple practical criteria. And in the end, it is the compactness, readability, and maintainability of our code that matters. So what I’m going to do is to write a very simple class with dependencies on a database, write an integration test that illustrates how inconvenient is to drag these dependencies with such simple class, and then show how to break the dependencies: first using traditional mocking with recorded expectations, and then using more lightweight arrange-act-assert approach that does not require accurate reconstruction of mocked object behavior.

The code that illustrates this article uses Typemock Isolator framework.

1. Code to test: calculating insurance price group

Our goal is to write tests for an algorithm that calculates a price group for car insurance. For simplicity the algorithm is based only on customer age: people under 16 fall into a Child group (with great chances to be refused), people between 16 and 25 belong to Junior group, age of 25 to 65 puts them into an Adult group, and anyone older is considered to be a Senior. Here’s the code:

Another issue is a visibility of Customer constructor. This is how it is defined:

C# code sample

Our tests will be written in a different assembly, so we won’t be able to create a Customer object directly. It is supposed to be instantiated only from a DataLayer object that is defined below:
public class DataLayer

C# code sample

Of course, the real DataLayer definition won’t throw exceptions: it will perform a series of well-known steps: obtaining connection strings, connecting to a database, implementing IDisposable interface, executing SQL queries and retrieving results. But for us it does not matter because the purpose of our work is to write and run test code without connecting to a database. Therefore it makes no difference if I instantiate and execute an SqlCommand or simply throw an exception: we don’t expect a database to be reachable, we haven’t created required tables and stored procedures, and any attempt to execute an SQL query will fail. So let’s not focus on database code, we assume other developers will fix it.

2. Integration tests

So we are ready to test GetCustomerPriceGroup method. Here’s how the body of a test might look:

C# code sample

No, that won’t work. Notice hard-coded customer ID passed to GetCustomerPriceGroup method. We must first create a customer that would belong to an adult price group and pass the ID returned by CreateCustomer to a GetCustomerPriceGroup call. Data creation API often is separated from data retrieval API, so in a larger system CreateCustomer method might reside in a different assembly. Or even worse – not even available to us for security reasons. In case it’s available, we have to learn new API, just for use in our test code. It shifts our focus from our main job – write and test CarInsurance class.
Here’s integration test code:

C# code sample

If we compile and run this test we will receive the following output:

Not very encouraging, isn’t it? We spent some time to learn customer creation API, expanded our code to create a customer record – only to find out that the database is not available. Some developers might object that this is not a bad experience: we need integration tests at some level. Yes, but should we write any test as an integration test? We are testing a very simple computational algorithm. Should this work include setting up a database and its connection strings and learning customer creation API that we haven’t used until now?

I must admit that many (actually too many) tests that we have in our company have been written like the one above they are integration tests. And this is probably one of the reasons the average test code coverage for our projects is still at 50-60%: we don’t have time to cover all code. Writing integration tests requires extra effort, and fixing broken integration tests is even bigger effort over time. It’s useful when hundreds of integration tests fail for different reasons. It becomes boring when they all fail due to a change in a single place. So we can draw a couple of conclusions:

• Writing integration tests requires learning additional APIs. It may also require referencing additional assemblies. This makes developer’s work less efficient and test code more complex.
• Running integration tests requires setting up and configuring access permissions to external resources (such as database).

In the next section we will see how we can avoid this.

3. Unit tests with traditional mocking

Now that we know that writing integration tests when the actual purpose is to test a small unit of code is not a good idea, let’s look at what we can do. One approach is to inherit DataLayer class from IDataLayer interface and then implement an IDataLayer-derived stub which would return a Customer object of our choice. Note that we won’t just need to change DataLayer implementation, we will also have to change the visibility of Customer constructor that is currently defined as internal. And while this will obviously make our design more testable, it won’t necessarily make it better. I am all for use of interfaces, but not for relaxing visibility constraints without important reasons. But isn’t class testability important enough? I am not sure. Bear in mind that making class instantiation public does not open it only for testing. It also opens it for improper use. Luckily, starting from .NET 2.0 an assembly attribute InternalsVisibleTo opens internal definition just for explicitly selected assemblies.

Anyway, we’ll take another approach: we’ll use mocking. No need to change the implementation of other classes, no need to define new interfaces. Using TypeMock framework a new version of our test will look like this:

C# code sample