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.

It's with great excitement that I am finally able to introduce the world to Teos. This company has been my vision for a very long time. Now that I have accumulated years of experience and expertise, I want to share my passion for creating great software with you. Quality and Usability have always been the core tenets of my practice, and you will hear a lot about those topics from me.

Quality is what distinguishes exceptional software from the rest. I've been in this industry long enough to have seen many ways of creating software that work. I've also seen many that don't. I'm sure I've even been guilty of a few anti-patterns in my life.

However, I've also brought successful projects to market by championing test automation, continuous integration, continuous delivery, and adherence to Agile principles. In the upcoming articles in my blog, I plan to delve deeper into each of these topics, because they all contribute to a quality product.

Software usability essentially describes the quality of the human-computer interaction. Whether you're talking about a web site, mobile app, traditional desktop application, or one of today's IoT devices, at the forefront must be consideration on how the user will actually use the thing. This can include visual elements, audio, and workflow.

I tend to favor a minimalist approach that doesn't burden the user with unnecessary information. With all of the things biding for our attention, from devices to dogs, we tend to be overstimulated in today's society. This shouldn't extend to our interaction with computers or devices.

The user should be presented with what they need, in order to accomplish what they want to do. They shouldn't have to sort through a bunch of unwanted data to find what's relevant. Think about the early search engines, and which one ended up on top.

Look forward to discussions like this, and many more, to come in the weeks to follow. In the meantime, please take a look around the site and explore the services we offer. What can Teos and you accomplish together?