Testing Dynamics CRM – Breakdown | Capsule Series
You are reading the second part of the main article: Testing Dynamics CRM.
Dynamics CRM can be divided into logical units that facilitate its testing by slightly adding twists to known methods wrapped in innovative tools. Let’s define the problem of each testable piece first to find value in what those tools provide us.
Database
In order to test any of the following units, we must simulate our data in memory somehow. For example, if we assume that our business logic associates a contact with a parent account, automatically using a plugin, then we have two ways to go about it.
One way is to directly map each request to a predefined response. This approach is, of course, tedious and wastes too much time. In addition, if the query changes for any reason, the developer must change the mapped response as well. This makes the whole system fragile.
The other approach is to provide the mocking engine with a list of accounts to choose from and the engine handles processing the request. This effectively simulates the query engine in memory. It requires so much more effort to get it right and cover all the details, but the reward makes it so worth the headache.
SDK
Testing the SDK in any context requires simulating all web service calls to CRM on our machine. Successfully simulating this amount of calls is a feat on its own right: from simple CRUD operations; to complex data and metadata queries, and an enormous number of specialised messages.
The time spent to build such a framework must be justified; is it worth the effort or should we favour the short term and fake each call, in code, on the fly.
Plugins
Plugins and custom steps have the same fundamental issue: they both run inside CRM in a special environment. This makes testing them a little bit harder than usual.
Both require the developer to build a special object — the context — containing parameters that are provided at runtime. For example, the message, target of execution, user and organisation ID, queried data … etc. Preparing those parameters can be tedious, which could become a burden on developers, leading them to skip testing altogether.
JS
Client-side code requires a library which is provided at runtime on page load in CRM. The client-side SDK is composed of well-defined functionality groups, each group performs a simple action on the form. Considering there aren’t that many actions compared to the server-side SDK, mocking can definitely be done relatively easy.
There is still the issue of testing web service calls, but it’s not specific to JS, or CRM for that matter.
System Flow
What if you want to test the effect of creating a record? Which plugins and WFs would fire, in what order, and let’s debug them on the fly while we are at it. Simulating this whole flow on your machine is definitely a dream for us, or any software engineer for that matter.
We have to build the plugin contexts on the fly, order their execution correctly, and track their effect on CRM. For WFs, we have to build an execution engine and parse their XAML correctly.
UI
QC teams usually performs system testing through the UI. Manual testing might not be the best approach in this case, due to our tendency to overlook details when faced with repeated actions.
There are two approaches to automating UI testing. Either use software that support recording a scenario, following user interactions with the UI, or manually write code that performs a series of actions on the UI when run.
Both would work in CRM to a degree; the issue is that CRM has a complex system of I-Frames and HTML structure. It takes some effort to trace the elements and their IDs needed for simulating actions. Even when you record the actions, you still need to tweak the steps due to animations and delays, changing frame IDs, or unique input elements, for example.
In the next part of the article, we will go deeper into the details of the testing activity itself from different perspectives using specific tools.
