Unit testing custom Microsoft Dynamics CRM code

When writing custom code that interacts with Microsoft Dynamics CRM, it is important to:

Unit test your code
Use an automated unit testing framework to automate your unit tests
Write unit tests that do not depend on external resources such as a Microsoft Dynamics CRM application server or SQL Server

Over the course of my next several posts, I'll be showing you some best practices for unit testing Dynamics CRM-facing code using Visual Studio unit testing tools and the Moq object mocking library. But before we get to the how, I'd like to spend the rest of this post talking about why the points I mentioned above are important.

Why unit test?

Looking at a high-level software development lifecycle of analysis-design-build-test-deploy, it’s generally accepted that the later a defect is identified in the lifecycle, the more it costs to fix. Consider the following example. A developer who is working on a method that adds two numbers accidentally types "-" instead of "+" in the code. If the developer catches the error before checking in the code, the cost incurred (in time and dollars) to fix it is negligible. On the other hand, if the defect slips through all the way to production, fixing it now requires not only changing the code, but also potentially fixing impacts to other components, rewriting documentation, redesigning training materials and redeploying the package, not to mention the loss of goodwill from the customer.

In addition to minimizing the cost of defect remediation, there are several other reasons to adopt unit testing. According to the Wikipedia entry on unit testing, there are five main benefits:

You will find defects earlier in your development cycle.
Unit tests make for easier refactoring and other code changes.
A comprehensive set of unit tests will make integration testing easier.
Unit tests can be thought of as "living documentation" for your code.
Unit tests, especially in a test-driven development methodology, are quasi-design documentation.

Why use an automated unit testing framework?

As the name suggests, an automated unit testing framework allows you to automate your unit tests. This lets developers quickly and easily run tests throughout the build process. By not requiring manual action to run unit tests, costs are also minimized. An automated testing framework is also necessary for continuous integration, but that's a topic for another time.

Why write unit tests that do not depend on external resources (Dynamics CRM application server, SQL Server, etc.)?

First, by definition, a unit test is a test of the smallest testable piece of an application. If your unit tests rely on accessing the CRM server, in addition to your code, you are actually testing network connectivity, CRM functionality, the database server and so on.

Second, trying to maintain an up-to-date Microsoft Dynamics CRM environment for unit testing is a pain. It's often hard enough to keep good data in a properly configured QA environment for integration testing and UAT, and it's even harder when you have to deal with multiple developers doing TDD maybe even before your actual QA environment is online.

To accomplish this goal, we need to use a mock object framework. Mock object frameworks allow unit tests to run your code against a mock CRM service so that the tests only validate that the code sends the right requests and correctly handles responses without requiring an actual CRM service.

How do you do this with Microsoft Dynamics CRM?

There are a number of unit testing tools for C# code, but in this series we'll exclusively use the unit testing tools that are available in Visual Studio 2012. Although I'll be using the built-in Visual Studio tools, you should be able to achieve the same results with alternative tools such as NUnit.

There are also multiple mock object frameworks for C#, but in this series we'll be using Moq. In the past, I've worked with Rhino Mocks, and while I still think it's an incredibly powerful tool, I think Moq is better for this series. Microsoft also offers a mock object framework called Microsoft Fakes that is available in the premium and ultimate editions of Visual Studio. So if you are using those, you may want to take a look at Fakes.

That's all for now. In my next post we'll get started testing. See you then!

A version of this post was originally published on the HP Enterprise Services Application Services blog.