Question

Trying to debug a plugin in CRM 2011 can be extremely difficult. Not only are there issues with having the .pdb files in the correct location on the server, but each time you make a coding change you get to go through the hassle of deploying and re-registering the plugin. Since the trigger is in CRM itself, it’s hard to create a unit test for it.

My current process of writing a unit test for a brand new plugin is rather slow and error, but goes something like this:

1. Register the new plugin using the SDK plugin registration tool
2. Attach a debugger to the w3wp.exe, putting a break point in the plugin code.
3. Trigger the plugin through whatever action it is registered to run for.
4. When the break point gets hit, serialize the preimage, postimage, and target values of the pipeline to XML files, this then becomes the input to my unit test.
5. Stop debugging and create a new unit test, using RhinoMocks to mock the PluginExecutionContext and ServiceProvider, using loading the serialized XML files as stubs for the input parameters.
6. Create methods that get run at the start and end of each unit test that resets (first attempting to delete, then add) dummy data for the unit test to process, then deletes the dummy data at the end of the test.
7. Edit the Serialized files to reference the dummy data so that I can ensure that the plugin will work against the exact same data each time it is ran.
8. Declare and instantiate the plugin in the unit test, passing in the mocked objects
9. Execute the plugin, running additional queries to ensure that the plugin performed the work I was expecting, Asserting on failure.

This is a pain to do. From getting the images correct, to creating the dummy data, and resetting it each time the test is run, there seems to be a lot of area for improvement.

How can I unit test a plugin without having to actually trigger it from CRM, or run through all the hoopla of debugging it in CRM first, and creating unique dummy data for each test? How can I use injection to eliminate the need to be deleting, creating, testing, verifying, and deleting data in CRM for each unit test?

Update 2016

This question is still getting quite a few hits, so I thought I’d add what the two (that I know of) open source projects that provide Fake CRM instances for unit testing:

• FakeXrmEasy — Created by Jordi (see answer below)
  • Primarily Fake CRM Service
  • Support for Plugin/Workflow Faking
  • Dependency on FakeItEasy
  • Great Documentation
• XrmUnitTest — Created by myself
  • Fake CRM Service + more (Assumptions, Entity Builders, etc)
  • Fluent Support for Plugin/Workflow Faking
  • No Dependency on any mocking framework
  • Sucky Documentation (I’m working on it)

Checkout this video I created to compare and contrast the differences.

Answer 1

How can I unit test a plugin without having to actually trigger it from CRM, or run through all the hoopla of debugging it in CRM first, and creating unique dummy data for each test?

With mocking. See this link for what classes to mock with RhinoMocks. Sounds like you are on your way in this regard.

How can I use injection to eliminate the need to be deleting, creating, testing, verifying, and deleting data in CRM for each unit test?

Injecting values for the input parameters can be done by stubbing in a hand-cranked instance of the entity you are going to manipulate:

// Add the target entity     
Entity myStubbedEntity = new Entity("account");
// set properties on myStubbedEntity specific for this test...
ParameterCollection inputParameters = new ParameterCollection();     
inputParameters.Add("Target", myStubbedEntity);     
pipelineContext.Stub(x => x.InputParameters).Return(inputParameters); 

Isnt that easier than capturing the xml data and rehydrating the entire input parameters collection?

---

EDIT:
for data access the usual recommendation is to wrap data access into classes. The repository pattern is popular but overkill for what we need here. For your plugins execution classes, you “inject” your mocked class at creation. A blank constructor that initalizes the default repository, and a second constructor that takes an IRepository.

public class MyPluginStep
{
    ITaskRepository taskRepository;
    public MyPluginStep(ITaskRepository repo)
    {
        taskRepository = repo;
    }
    public MyPluginStep()
    {
        taskRepository = new DefaultTaskRepositoryImplementation();
    }
    public MyExecuteMethod(mypluginstepparams){
        Task task = taskRepository.GetTaskByContact(...);
    }

Depending on the complexity of your plugin steps this can evolve into passing many repositories to each class and could become burdensome but this is the basics you can add complexity to if required.