How I develop and unit test CRM 2011 plugins

This is probably the most promised, but never published blog post on my list of potential posts.  I’ve managed to convince enough CRM developers I’ve run into that they should get some test driven development with unit testing religion.  Especially because of the added productivity benefits for CRM plugin development.  This post isn’t to convince you of the benefits of unit testing.  There are plenty of articles/blogs which cover that topic just fine.  I’m not interested in debating the virtues of unit testing.  Love it or leave it;). 

The purpose of this post/video is to show you how I develop and unit test plugins.  There are a few articles out there about how to unit test CRM 2011 plugins.  I haven’t been satisfied with the approaches I’ve seen.  I landed on an approach which combines using the CRM 2011 Plugin Testing Tools for mocking IServiceProvider and Moles fore detouring types used inside the plugin which are difficult or time consuming to mock such as OrganizationServiceContext, Web Service calls, and others.

You can grab the finished example here:

You can also grab the starter solution I mention in the video here:

Once you’ve learned the basics in the video, hop on over to the series below for some more advanced examples:

The series above focuses on using Fakes in VS2012.  Fakes is the successor to Moles. However, the general techniques still apply whether using Fakes/Moles.  If you are using VS2012, then use Fakes.  If you are using VS2010, then use Moles.

I find many people who are new to unit testing have questions about where it fits in relation to other forms of testing.  Unit testing does not replace other forms of testing such as integration testing (i.e. testing the plugin running in CRM).  TDD through unit testing is an upfront developer discipline.  It requires a certain culture and mindset on a dev team.  In my opinion and experience, it helps me produce better code and allows me to catch more (not all) bugs early on, before handing things off to other testers.  It also makes the others testers lives/jobs easier. 

When applying this approach to CRM plugins, there’s a bonus side effect that (for me) allows me to be more productive in authoring my plugin code because I can:

  • Iterate (make code changes, build, debug and/or test, repeat) rapidly without needing to deploy to a CRM server
  • Iterate on my code rapidly without affecting the external systems
  • Use code coverage to identify untested scenarios which enable me to build better, more complete tests. 
    • This, in turn, allows me to build better, less buggy code.
  • The nature of having a suite of automated tests allows you to identify issues and regressions in your code early on as you make changes
    • This becomes more and more valuable over time as you build out your plugins and corresponding tests
  • Other devs don’t have to know how to test your code.  They just run the tests you’ve written


Comments (6)

  1. Guru Prasad says:

    Thanks for the nice article.

    Will this solution works for CRM 2011 online?

    Are there any ways to debug CRM 2011 online plugin except using profiler?



  2. keydet says:

    Yes, this works with CRM Online plugins because you are doing everything locally, not in CRM Online.  Other than taking approach like this or what the profiler does, there isn't another way to debug in CRM Online.  Both this approach and the profiler do the same thing in slightly different ways.  They both bring state down from the CRM server enable you to re-create plugin execution locally.

  3. Brief and to the point! thank you for this article!

  4. Alcibiades says:

    Your article and video were simply wonderful! Thank you.

  5. Vishal says:

    Hi, I was looking for .xml files on CRM server but there are no xml files on server where elas I can find those files.

  6. bryanhdl says:

    It tried dynamics online version and could not find xml file in Windows/Termp folder. Where can I find xml file?

Skip to main content