Our Thinking

In my last post, I showed how you could use mocking frameworks and dependency injection to create unit tests for methods that query a database using Entity Framework. In this post, I will show how you can use the same techniques to test data access code that will insert, update or delete a record from the database.

Recently, the data access technology that we have relied on for most of our projects is Entity Framework. Entity Framework is an excellent tool that makes it easy to work with a database using the .NET code that we are most familiar with. However, out of the box, Entity Framework does little to help support automated unit testing. Specifically, the DbContext is not interface-based and does not provide a clean way to support mocks. This makes it difficult to write a unit test that doesn’t require database access, which would result in slow and error-prone tests.

In my last post, I mentioned that one problem with my earlier unit tests was their dependency on database access. Having my tests directly dependent on the database created slow-running tests and tests that were prone to failure as the database changed. Over the course of this post, I’m going to demonstrate some of the techniques I have learned that provide the ability to decouple a set of code from using direct database access. Note that the examples are in C#; however, the principles apply to any object-oriented language with a unit testing framework.

For my entire career as a software developer, I have believed that unit testing is an essential activity that is part of delivering a quality product. However, what that means to me has gone through multiple revisions. This post is not intended to give a detailed overview of how to write unit tests or any specific unit testing practice. What I intend is to take you through my journey and a few things I’ve learned as I’ve incorporated automated unit testing into my developer’s tool belt.

Most teams that I have had the chance to work with seem to go through the Group Formation Stages of “forming, storming, norming, and performing” identified by psychologist Bruce Tuckman. As a Scrum Master, it is necessary to help teams navigate through these stages so that they can become highly performing teams.