Overview

This blog post represents a high level example of how to create and unit test a Dynamics 365 plugin.

Creating the plugin

JourneyTeam.Xrm

On line 10 of Figure 1, it’s implementing BasePlugin rather than the IPlugin interface. BasePlugin has been designed by JourneyTeam.Xrm. There are benefits to using a wrapper like this rather than directly using IPlugin. Benefits such as specifying the event/s that the plugin will handle (as defined on line 15). This specifies that the plugin is expecting the specified event to be registered. If another event is registered by mistake, it will generate a plug-in trace log message such as: “No Registered Event found for event: Update, Entity: cpl_initialinterview, and Stage: PreValidation!”

SOLID principles

The business logic has been separated out from the plugin and an attempt has been made to follow SOLID principles.

Figure 2 illustrates how an interface has been designed to encapsulate the logic of interacting with attributes on a form. Figure 3 illustrates the implementation of this interface for a specific form

Line 32 of Figure 1 represents how the function populateAttributesOnForm() is referenced in the plugin

Unit testing the plugin

When developing a plugin, it’s recommended to create unit tests at the same time (e.g. Figure 4). The reason being is that it’s a lot easier to debug a plugin in Visual Studio (i.e. stepping through the plugin code) rather than adding trace statements in the plugin code and continually re-uploading the assembly.

The NuGet packages installed in the Plugins.Test project are:

• FakeXrmEasy.v9 version 2.3.1
• xunit version 2.4.2 – allows the test system to be able to find the unit tests