Creating a plugin and unit testing it with FakeXrmEasy

Please note that there are issues with this blog post. That is, the assert statements in Figure 4 aren’t actually testing anything.

Overview

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

Creating the plugin

Figure 1

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

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

Figure 3

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
Figure 4
Figure 5