Automated Testing for Microsoft Dynamics CRM 2011: Part I – Plug-in Profiler
Unit testing for Microsoft Dynamics CRM plug-ins has been an active topic for a while, but most of the approaches have a significant barrier to entry for those who are not already experienced with NUnit/Rhino/Moq/Fakes/Moles/etc – the primary issues (in my opinion) being:
1. How to generate plugin ‘context’ files for each test case, and how to trigger repeatable executions of that saved plugin context against a given plugin assembly and method.
2. How to deal with SDK calls that are encountered within the context of your plugin code (e.g. auto-creating a task when a new lead is created)
For this post, I’m focusing primarily on issue #1, although it also leads towards a solution for #2 as well, to be discussed later.
I’ve used the principles discussed in this article to build a small automated testing utility for plugin assemblies, but for clarity I’m going to leave the discussion of that utility for a later post (or possibly Marketplace or CodePlex). What I’d like to focus on in THIS post is what we can leverage right out of the existing SDK.
Introduction to the Plug-in Profiler
Rather than go into an extended discussion of Plug-in Profiler here, I’ll just link to some useful background information on Microsoft’s website:
Essentially, the Plug-in Profiler can be used (either standalone or from within the Plug-in Registration tool) to record and replay ‘profiled’ plugin events. This essentially gives us the first half of problem #1 above – how to generate saved ‘context’ files of a plugin execution for later execution as ‘test cases’.
It also provides a manual mechanism for selecting a saved ‘profile/context’ file and re-executing it against a selected assembly, including a log of any exceptions, profile traces, etc. – but each run must be configured manually (select the saved file, select the assembly, etc.)
The missing link here to make a major leap towards automated testing is to provide the ability to process through a series of ‘saved’ plugin execution profiles and log the results (rather than only one at a time). To that end, I went searching in the source code for the Plug-in Registration tool.
Getting What We Need from the Plug-in Registration Tool Source Code
Basically, all I wanted to pull out of the Plug-in Registration tool was the code that was used to execute saved profiles, so that I could take that same code, and execute it in a loop, based on a configuration xml file. What I ended up with were essentially two calls from the Plug-in Profiler assemblies.
Note: To utilize these from within your own utility, obviously you need to reference the CRM SDK /bin folder’s Plug-in Profiler assemblies
The primary difference between these is whether or not you are passing in an OrganizationService Proxy or not (No – Replay, Yes – Execute). I won’t spend any more time on the differences right now…we can come back to that in the future.
In order to set up the execution of the methods above, we have to give the plugin profiler a set of execution parameters for each of our ‘tests’, which could easily be configured in an XML file read by the utility:
* Isolation Mode
* Path to the assembly
* Which plugin class to execute against
* Path to the saved test ‘profile’
* Plug-in Unsecure Config string
* Plug-in Secure Config string
Which, using the plugin profiler assemblies and classes within them, ends up something like this:
* currentTest – this is an object that contains my configuration values for each configured ‘test’. (class generated via xsd.exe)
* assembly = path to the assembly to test
* plugin = C# type of the plugin class to be invoked
* profile = path to the saved ‘profile’
* unsecureConfig / secureConfig = just what you would think
* service – this is an IOrganizationService I create elsewhere
* the rest of the objects below are coming from the PluginProfiler library references.
The sample code above is an example of how to take a ‘saved’ profile captured using the SDK tools (Plug-in Registration/Plug-In Profiler) and programmatically execute it. The next installment will reveal one way to build on this to address some other complications of automated testing like:
1. Checking pre- and post- conditions to determine test success
2. Verifying ‘downstream’ SDK calls for success
3. Configuring ‘tests’ prior to development to move towards Test Driven Development
If you’re using CRM as a platform for deploying line of business applications, make sure you’re getting the most from your investment by reading CRM Governance: What It Is, What It Isn’t, and How to Do It Right, an informative eBook written by governance experts.