In parts one and two of this series, I gave an introduction to unit testing Dynamics CRM C# interfaces code with mock objects using NUnit and Moq, and I showed code samples for a couple of different scenarios. In this post I will show how to work with CRM metadata (optionset values, statuscode values, etc. »
Earlier this week I wrote a post that gave an introduction to unit testing Dynamics CRM C# interfaces code with mock objects using NUnit and Moq. The sample code in that post was extremely simple, so I wanted to follow up with a more complex example that shows how to test multiple calls to the CRM web service instead of just a single one. »
A while back I wrote a post that gave a high-level overview of some of the tools I had used at a previous job to do unit testing of Dynamics CRM interfaces code, but I didn’t get into the why or how. Here is an introduction to unit testing Dynamics CRM code using an automated unit testing framework and a mock object framework. »
I’ve typically preferred to access Dynamics CRM data using SQL queries, so I have never worked much with FetchXML. I’ve recently started working on a bit of a hobby project where it makes more sense to populate a datatable from using FetchXML than to use a SQL query, but unfortunately I have encountered three differences between FetchXML and direct SQL that I don’t particularly like: »
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. »