Minimum Version: 2.1.0
Plugin Step Auditing is a feature that we used internally to develop and test the pipeline simulation and it could be useful to write tests against complex plugin interactions.
Plugin Step Auditing stores an audit of all the plugin steps that are executed during pipeline simulation, and it stores them in the exact same order they occurred.
This might be useful to write assertions to validate the sequence of certain plugin step executions without the need to debug them, or without the need of duplicating unit tests for said executions. The idea of using plugin auditing, is to verify that a given plugin was just executed for given message, stage, mode and so on. This will help you keep test data small as you won’t have to test the same plugin logic again, other than the unit tests you had for said plugin.
If you compare this feature with another mocking framework, this would be like the “test plugin A was executed with X parameters” pattern and forget about it :)
An audit of plugin steps also stores information about the context of that execution.
Auditing of Plugin Steps is disabled by default but in can be enabled in the middleware configuration via the PipelineOptions class.
The following section describes how to enable and use the Plugin Step Auditing functionality.
If you want to enable plugin step auditing please set the UsePluginStepAudit property to true in the middleware setup as follows:
return MiddlewareBuilder
.New()
// Add* -> Middleware configuration
.AddCrud()
.AddFakeMessageExecutors()
.AddPipelineSimulation(new PipelineOptions() { UsePluginStepAudit = true })
// Use* -> Defines pipeline sequence
.UsePipelineSimulation()
.UseMessages()
.UseCrud()
.Build();
Once auditing is enabled, you could write assertions that use the audit capability to verify plugin step executions.
Once enabled, you could retrieve the plugin step audit via _context.GetPluginStepAudit() method.
The PluginStepAudit interface comes with a CreateQuery() method that will allow you to perform any kind of query against the audit.
For instance, the sample code below checks that the AccountNumberPlugin was executed against the Create message and a given stage (Prevalidation, PreOperation or PostOperation).
using FakeXrmEasy.Plugins.Audit;
//...
var pluginStepAudit = _context.GetPluginStepAudit();
var stepsAudit = pluginStepAudit.CreateQuery().ToList();
Assert.Single(stepsAudit);
var auditedStep = stepsAudit[0];
Assert.Equal("Create", auditedStep.MessageName);
Assert.Equal(stage, auditedStep.Stage);
Assert.Equal(typeof(AccountNumberPlugin), auditedStep.PluginAssemblyType);
Minimum Version: 2.3.3 / 3.3.3
With this version you can now query what was the secure and unsecure configuration that was passed into the plugin step. This might help in troubleshooting scenarios.
///... omitted for simplicity
var auditedStep = stepsAudit[0];
Assert.Equal(secureConfig, auditedStep.PluginStepDefinition.Configurations.SecureConfig);
Assert.Equal(unsecureConfig, auditedStep.PluginStepDefinition.Configurations.UnsecureConfig);
Minimum Version: 2.3.3 / 3.3.3
With this version you can now query what was the specific plugin instance that triggered a specific plugin execution. This might help in troubleshooting scenarios.
var pluginInstance = new CustomInstancePluginPipeline("My Injected Value");
///... omitted for simplicity
var auditedStep = stepsAudit[0];
Assert.Equal("Create", auditedStep.MessageName);
Assert.Equal(pluginInstance, auditedStep.PluginStepDefinition.PluginInstance);