Often we hear the term Test driven development (TDD) in software development life cycle. However, can we do TDD to develop the extensions in Dynamics CRM development? What are the prerequisites? Do we need Dynamics CRM instance? Let’s see.
In this article, I will discuss how we can achieve TDD while developing plugins and custom workflows.
When plug-in or workflow is created, often developer’s register the assembly & steps in a CRM instance and try to execute to see if the plug-in or workflow is executing correctly or not. In other case, create a console application and test the logic and then update plug-ins and workflows. Using a testing framework like Rhino Mocks, code is tested and checked for % of code coverage, debug and fix issues in the logic. Rhino Mocks’ unit test’s enables us to integrate with TFS builds and Check-ins, which means System can run the tests before code check-in or during nightly builds. Using Rhino mocks as testing framework, one positive and negative testing can be achieved as well as test all the exceptions.
In terms of prerequisites, where custom logic is to be written due to a business requirement,, Visual Studio is used as a development environment and Rhino Mocks as testing framework. Dynamics CRM instance is not required. Yes, you read it correct, you don’t need Dynamics CRM instance to test custom plug-ins or workflows.
Rhino Mocks is a dynamic mock object framework for the .Net platform. Its purpose is ease of testing; by allowing the developer to create mock implementations of custom objects and verify the interactions. Rhino Mocks will generate fake objects to replace the dependencies that exist, and at run time, allow the system to behave accordingly. Introduction and how Rhino mocks works is a separate topic which is not covered in this article. This article only covers how it is used with Dynamics CRM extensions.
As specified earlier, Visual studio is used as development environment. Dynamics365 SDK assemblies and Rhino Mocks assemblies are available for download using nuget package manager within Visual Studio.
Dynamics365 SDK assemblies allows us to write plug-in or custom workflow logic. And Rhino Mocks allows us to created test project with required test methods.
Let’s take an example where user wants to attach a csv file with contacts to quotes and associate contacts to Quote record in CRM
Create a plug-in which triggers on attaching a csv file to quote record and invoke the logic to associate contacts to quote record
- Validate the context by checking target entity, regarding object and the file name .
Setup Test Initialize method where all objects are set with Mock repositories.
Set all expectation methods. This will help us to decide the behavior and expectations of the mock object.
Below example to set expectation on _executioncontext object regarding depth.
Similarly setting expectation for the trace object
Here input parameters on the execution context were set.
Test happy path for plug-in execution. In this method,
- Create an entity object annotation with few attributes like filename, objecttypecode, documentbody and objected
- Set context Depth as expectation making sure plug-in depth is 1.
- Added trace expectation as, I am expecting my plug-in to provide this information in case of any expectation.
- Setup Input parameter collection property on the plug-in execution context object
- Invoke the plugin
- Verify all expectations set.
Test exceptions scenario where plug-in throws and exception
- This is similar to normal test method however this method expects an invalid plugin execution exception in return.
- Setup process for all objects remains same.
- As part of this method, I am expecting a organizationservice.create method to be invoked. In this scenario, if there is an issue with the creating contact, organization service.create method will throw an expectation.
So set an expectation on organizationservice that when create method is invoked throw an invalid plugin execution context exception
This section focuses on custom workflow which return an output parameter. Though testing workflows and plug-in is similar, there is a minor difference in how workflows with output parameters are tested.
We have a workflow which requires a key name as input parameters and return wait time as output parameter
Setting up test profile
There is a slight change in the way workflow test initialize method created.
Test the actual method which returns wait time as output parameter
- In this scenario, create dictionary objects to hold input parameters, expected output and actual output parameters objects
- Set parameters and other expectations
- Invoke workflow with input parameters and expect out parameters
- Use assert method to compare the values.
Rhino Mocks helps to test Dynamics CRM plugins and workflows and deliver quality code. Hope this article provided you with sufficient details to start with Rhino Mocks to follow TDD approach in developing and delivering plug-ins & custom workflow.