Our Thinking

As Agile coaches, it is not uncommon for us to encounter companies that have made adopting Agile a priority in their organization but have come under scrutiny for not delivering any specific business value - despite what was promised. In many of these cases, we have seen these organizations revert back to their traditional ways of delivering projects, while others take a mix and match approach relegating Agile only to small co-located projects.

So, you’ve adopted Agile as your company’s method for project delivery. You packed up your books on traditional development best practices (lovingly referred to as waterfall or sequential) and put them in storage. You’ve invested sufficient time and money to ensure that every stakeholder has taken all the necessary training. You’ve setup all the required tools of the trade – installed white boards, hoarded bunches of post-it notes, identified space for stand up meetings, partitioned a large white wall with magnetic strips to show movement of work, etc. 

Things should be ticking along perfectly now. Right? Releases should be visible, you should be getting the maximum value out of your development teams, clients should be satisfied, and the quality of your product should be exceeding your customer’s expectations. Did you say, “Not really”? 

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.