How do I correctly setup C# unit tests for CRM 2011 plugins?

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 m

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.

Answer 2

One really good option would be to use a mocking library which deals with mocks and fakes for you because I wanted to create my own and always ended up wasting a lot of time creating fakes or mocks until I created this library which does it for you. Try FakeXrmEasy

Answer 3

I serialize the plugin execution context to file for use with unit tests. There is a good project on codeplex that does this http://crm2011plugintest.codeplex.com/

Makes debugging and unit testing easier and you can 'record' real world testing.