If you're developing code that runs against Dynamics CRM, you know you should be testing it, right? As a developer first and foremost, I always believed that tests and documentation got in the way of the important - and more fun - stuff, but as I transitioned into a management role with responsibility for my company's Dynamics CRM system, I began to appreciate the value of the less-fun stuff.In this post I'll give you an overview of our continuous integration environment and offer a conceptual example of how to unit test your CRM code without having to execute tests against a running CRM system.Our full build and unit testing process used the following:

1. NAnt for builds

2. NUnit for unit tests

3. Subversion (SVN) for version control

4. CruiseControl.NET (CC.NET) for continuous integration

5. Rhino.Mocks for mock object framework

Whenever a developer made a commit to SVN, CC.NET would execute the correct NAnt build target (different ones for production, testing, etc.), then it would run the NUnit tests. The results of the build (broken/successful) and the results of the NUnit tests were all reported through the CC.NET web interface so you could see a historical view. CC.NET also has a desktop notification app that is green when all builds are good or red when all builds are bad that you can use to easily check up on your development team.

Originally our NUnit tests ran against our CRM staging server and staging database, but we found that it was a problem keeping the staging system populated with "real" data, and our staging system was underpowered, so unit tests took a long time to execute. We solved this by using Rhino.Mocks to setup a mock CRM framework to verify that our code would send the correct calls to CRM without actually having to make the calls against an actual system.

Here's a conceptual example from version 4, but it will work similarly in 2011. Let's say we want to test code that deactivates an account. First, the test method sets up a mock object to represent the CRM service. Second, we set up an object to retrieve the setstate request object that the production code will pass to CRM. Third, the test method runs the production code against the mocked CRM service and captures the request object. Finally, we test the properties of the request object using an Assert.AreEqual call.

If you're ready to dig into the technical details of Rhino.Mocks + CRM, take a look at this excellent blog post with code samples: http://www.develop1.net/public/post/Unit-Testing-Dynamics-CRM2011-Pipeline-Plugins-using-Rhino-Mocks.aspx.

In Dynamics CRM you may have a field you want to be required some of the time, but not required, or maybe not even enabled, the rest of the time. In this post I'll show you how to dynamically enable/disable and set/unset the required attribute of CRM form fields using JavaScript.

Let's say you have a delivery restaurant that sells pizza and wings. You could store the order attributes in CRM on a custom DeliveryOrder entity. You could have a picklist to represent the order type, pizza or wings, and you could store the pizza toppings in a text field. If the order type is pizza, you want to require something be entered in the toppings field. If the order type is wings, you don't want to even allow an entry in the toppings field.

First, create the entity attributes. We'll call the picklist lucas_ordertype, and we'll call the text field lucas_toppings. The picklist values for lucas_ordertype are Pizza and Wings, and it is a business required field. When you create the lucas_toppings field, don't change the default requirement attribute.

Once you've added the fields to your CRM form, you'll need to add some JavaScript to enable or disable the toppings field and set its requirement level appropriately. Here's script that does it:

//get a references to our picklist object  
var oOrderType = crmForm.all.lucas_ordertype;  
  
//default toppings field as disabled, not required  
crmForm.all.lucas_toppings.Disabled = true;  
crmForm.SetFieldReqLevel("lucas_toppings", false);  
  
//if order type is pizza, enable and require toppings field  
if(oOrderType.SelectedText=="Pizza")  
{  
crmForm.all.lucas_toppings.Disabled = false;  
crmForm.SetFieldReqLevel("lucas_toppings", true);  
}

Add this script to the form's onLoad event and the lucas_ordertype field's onChange event, and you're set. Now you'll get the information you need without unduly inconveniencing your users.

At a previous job, we had used GoldMine (version 6.7 was where we parted ways) as our CRM system before moving to Dynamics CRM. At the time - maybe it's still done this way - GoldMine allowed you to code activities with a hierarchy of references, codes and results. We used reference to separate activities either by department or broad functional grouping (e.g. "service" was a separate reference although there was no separate "service" department). Codes were the specific kinds of activities or client touch points grouped under a reference, and the results indicated how the activity concluded.

The reference/code/result structure allowed us an incredible level of granularity for tracking all the times we either interacted with an external stakeholder (client, prospect, partner, external service provider) or did something on its behalf. We were able to compile detailed "production" reports for our call center reps, and the activities' structure gave them a framework for approaching their routine daily responsibilities.

Here's a simple reference/code/result example:

• Reference - Sales
• Code - 1PC//Prospecting call_ (In GoldMine everything before the // was treated as the picklist entry's primary key, so the 1PC would be stored in the database. We would then speak of 1PC calls as a shorthand.)_
• Result - 1LM//Left message

We tracked everything this way. Despite us still using GoldMine 6.7 in some parts of our business all the way into 2008, activity tracking was great except for two problems. First, although the codes existed in our processes as a logical hierarchy, GoldMine didn't understand that. If you picked the "sales" reference, you still had to weed through all the codes and results that corresponded to all the other references. Second, adding new reference/code/result entries in a supported manner took a lot of time.When we started considering the move to CRM 3 in 2005, I found the default activity entity structure to be something of a letdown, so I brought the reference/code/result framework over when we actually did move. Here's how I did it.

First, I created three separate picklist attributes in CRM on the six main activity entities we used - appointment, e-mail, fax, letter, phone call and task. Let's call them lucas_reference, lucas_code and lucas_result. I then populated them with the existing references, codes and results from GoldMine. The following are not the actual codes, but they'll give you a decent idea of how things were structured.

References (lucas_reference)
Sales
Service

Codes (lucas_code)
1CD//Contract discussion
1PC//Prospecting call
1PE//Prospecting e-mail
1FC//Follow-up call
1FE//Follow-up e-mail
1SC//Suspect call
2CI//Service call inbound
2EI//Service e-mail inbound
2FU//Service follow-up

Results (lucas_result)
1CF//Contract finalized
1UP//Understands product
2CS//Customer satisfied
2CU//Customer unsatisfied
2IE//Issue escalated
2IR//Issue resolved
CRS//Call rescheduled
CMP//Completed
EMI//E-mail in
EMO//E-mail out
PCI//Phone call in
PCO//Phone call out
LVM//Left message

In this example, codes and results starting with 1 are children of the "sales" reference. Codes and results starting with 2 are children of the "service" reference. Codes and results starting with letters are general options available to any reference.

At this point, allow me to point out a few things. First, we didn't use the existing CRM service activity, and we rarely (practically never) used the fax or letter entities. Why we didn't is beyond the scope of this blog post.Second, the reference/code/result picklist entries were duplicated across all six activity entities even if they didn't make sense. That is, you could have a task with a result of "PCO//Phone call out." Because we had several hundred options, it was easier to make sure every activity had everything than to weed out the ones that didn't fit. Also it made report writing simpler.Third, the general options were handy for when we didn't have a firm process that applied to the activity. For example, sometimes on the service side, all we could do was note that a call came in.Fourth, reference and code were business required. Result was not because you obviously wouldn't know a scheduled activity's result at the point in time when you created it.

Once I created and populated the picklist attributes, I added them to the entities' forms, which was simple enough, but you'd still have the GoldMine problem of every code and result being available for any reference. I took care of that with a bit of JavaScript.The following example is based on something I picked up from "Working with Microsoft Dynamics CRM 3.0" by Mike Snyder and Jim Steger.

var objRef = crmForm.all.lucas_reference;  
var objCode = crmForm.all.lucas_code;  
var objRes = crmForm.all.lucas_result;  
  
//get the currently selected code and result values so we don't lose data if we're editing an activity instead of creating a new one  
var curcode = objCode.DataValue;  
var curresult = objRes.DataValue;  
  
//set the lucas_code and lucas_result picklist options to empy arrays for now  
var oTempArray = new Array();  
objCode.Options = oTempArray;  
var oTempArrayRes = new Array();  
objRes.Options = oTempArrayRes;  
  
//if a reference is selected  
if(objRef.SelectedText!="")  
{  
//get prefix of codes we're going to enable  
var codePrefix = "";  
var resPrefix = "";  
switch(objRef.SelectedText)  
{  
case "Sales":  
codePrefix = "1";  
resPrefix = "1";  
break;  
case "Service":  
codePrefix = "2";  
resPrefix = "2";  
break;  
}  
  
//enable the correct code codes  
if(codePrefix != "")  
{  
//loop through the original lucas_code options  
for (var i = 1; i < objCode.originalPicklistOptions.length; i++)  
{  
//if the lucas_code option begins with the codePrefix, add it to the holding array  
if(objCode.originalPicklistOptions[i].Text.indexOf(codePrefix)==0)  
{  
objCode.AddOption(objCode.originalPicklistOptions[i].Text, objCode.originalPicklistOptions[i].DataValue);  
}  
}  
  
//make sure the picklist is enabled  
objCode.Disabled = false;  
  
//set the picklist's selected value to what we stored earlier  
objCode.DataValue = curcode;  
}  
else  
{  
//disable the field  
objCode.Disabled = true;  
}  
  
//enable the correct result codes  
if(resPrefix != "")  
{  
//loop through the original lucas_result options  
for (var j = 1; j < objRes.originalPicklistOptions.length; j++)  
{  
//if the lucas_result option begins with the resPrefix, add it to the holding array  
if(objRes.originalPicklistOptions[j].Text.indexOf(resPrefix)==0)  
{  
objRes.AddOption(objRes.originalPicklistOptions[j].Text, objRes.originalPicklistOptions[j].DataValue);  
}  
//handle some general cases  
if(objRes.originalPicklistOptions[j].Text.indexOf("CRS")==0)  
{  
objRes.AddOption(objRes.originalPicklistOptions[j].Text, objRes.originalPicklistOptions[j].DataValue);  
}  
if(objRes.originalPicklistOptions[j].Text.indexOf("CMP")==0)  
{  
objRes.AddOption(objRes.originalPicklistOptions[j].Text, objRes.originalPicklistOptions[j].DataValue);  
}  
}  
  
//make sure the picklist is enabled  
objRes.Disabled = false;  
  
//set the picklist's selected value to what we stored earlier  
objRes.DataValue = curresult;  
}  
else  
{  
//disable the field  
objRes.Disabled = true;  
}  
}  
else  
{  
//no selected reference, no displayed codes or results  
objCode.Options = oTempArray();  
objRes.Options = oTempArrayRes();  
  
//disable the fields for good measure  
objRes.Disabled = true;  
objCode.Disabled = true;  
)

Add that to the onLoad event for each activity form and the onChange event for the reference field on each activity form, and you're good to go.

Happy activity documenting!