About three years ago I released an open source Dynamics CRM solution for scheduling and executing recurring workflows. My solution would execute a FetchXML query to return a set of records and then start a workflow for each of those records without requiring any external processes or tools. This is a generalized approach to solving a class of problems that includes the following scenarios: »
When Dynamics CRM 2013 was released, I thought access teams were the new killer feature in that version, and I even developed custom workflow activity code to make managing access team membership easier by using connection records. I have thus far not had an opportunity to use access teams in a real project, so I was disappointed to read this blog post by Ben Hosking (AKA “The Hosk”) about how Microsoft doesn’t provide any out-of-the-box capabilities for moving access team templates between Dynamics CRM organizations. »
One of the main points of all my unit testing posts is that unit tests should be written so that you can test your code without needing to rely on external resources, and, we’ve been able to use Moq as a stand-in for Dynamics CRM’s related services without too much trouble. »
This is the final post in my series on unit testing custom Microsoft Dynamics CRM code in which I’ve been showing how you can unit test custom C# code that interacts with Microsoft Dynamics CRM using Visual Studio’s unit testing tools and Moq. We’ve looked at several different scenarios thus far, but none of them included the method under test throwing an exception. »
In my last post, I showed how to unit test a Microsoft Dynamics CRM custom workflow activity using Visual Studio and Moq. In this post I will show you how to unit test a Dynamics CRM plug-in. For this example we’ll be using the sample FollowupPlugin class in the CRM 2011 SDK, but the principles I will demonstrate are applicable to any plug-in. »