One component, upon which at many enterprise applications rely, is some form of database. It's often hard to get by without one or more, whether it's SQL, No SQL, or yet another technology. However, when you're unit testing such an application, you don't want to actually test against these real databases.

For starters, this gives you a huge performance hit. For a few unit tests, this might not be noticeable. However, once you start getting hundreds of unit tests in a gated build, this can really be problematic.

Second, testing against a real database means that your unit tests are dependent on the state of the database and each other.

One unit test can inadvertently affect another unit test, by altering data that is used by both. So tests might work one moment and fail the next. This can be extremely difficult to debug.

If that still hasn't convinced you, think of the potential deadlocks when all the unit tests being run by your builds and developers are all vying for attention from the test database. As you can imagine, this can be another performance hit and another opportunity to introduce intermittent failures.

Ultimately, when you test against an actual database, you're testing your Object-Relational Mapping (ORM) just as much as your own code. You want your unit tests to focus on testing your code, and leave the ORM and database for integration testing.

So, how do you provide access to your data, while still enabling unit testing? Let me introduce you to the Repository and Unit of Work design patterns. The Unit of Work encapsulates the database context, while the Repositories provide access to your data. All the while, everything is defined by interfaces so it can be nicely mocked by your chosen mocking framework. Take a look at the Unit of Work interface and implementation.

The Unit of Work is the sole provider of access to the Repositories. When it creates a Repository, it initializes it with the shared database context, which is encapsulated in the Unit of Work itself. Therefore, when any Repository performs an action, it's using the same context as the other Repositories. Furthermore, nothing is allowed access to the context except the Repositories.

In order to actually create a Unit of Work, a Factory is used to hide the underlying implementation. That means you can create a Unit of Work for unit testing as well as normal operations.

Once you have your Unit of Work, you can use it to access the Repositories. Take a look at the interface and implementation of the Repository.

The Repository class itself provides a generic implementation to perform CRUD operations on any type of data entity. Now that we have the Unit of Work and Repository implemented, it's time to take a look at a real example of how to use them. This example shows what a possible Service class might look like that consumes these interfaces.

As you can see from the example, the service used two Repositories to accomplish it's task. When it was done, it called SaveChanges, which committed the add as a single transaction.

Bringing it all together, we have the Unit of Work, which is responsible for the database context and the creation of the Repositories. Then the Repository is a generic interface which provides operations on any data entity. Finally, the Unit of Work provides a Save method to commit the operations as a single transaction.

Since everything implements an interface, it can all be mocked. Therefore, you have data access that can be easily unit tested without the need for a cumbersome test database.

The complete source code from this article can be found here.

Mocking is an essential component to any good unit testing strategy. It allows us to replace the concrete implementation of a class with a test version whose behavior you control. When designing a system from scratch, we can use dependency inversion to make sure everything is mockable. However, when working with an existing system, there may be hidden dependencies that require some creative thinking.

I recently came across a situation where I needed to unit test some code that had dependencies on Microsoft's OWIN extension methods. The methods in question belonged to the static class OwinContextExtensions.

OwinContextExtensions

I was using Moq as my mocking framework, which doesn't provide a mechanism for mocking static extension methods.

To overcome this hurdle, I created a wrapper class which exposed the same methods, but as instance methods. I then extracted an interface from my new wrapper class, so that I could mock it up. Here is the new interface for the wrapper class. Notice that it has the same methods as the original extension class, but as regular methods.

IOwinContextExtensionsWrapper

Finally, here's the wrapper class itself. As you can see, it still makes use of the original extension methods. However, this implementation is abstracted from the user, in this case the unit test.

OwinContextExtensionsWrapper

To bring it all together, once the wrapper class and interface were in place, it was time to wire everything up. First I had to create a number of mocks on which there were dependencies. In this case, the wrapper is provided to the controller by means of a property, which it later uses to get the UserManager.

In conclusion, if you encounter static extension methods when you're unit testing, don't panic. Just whip out a wrapper class and interface to break that hard dependency. This is just one example of overcoming a dependency in existing code. However, when designing for new functionality, always try to think of how you're going to mock the classes you create.