Integration testing / Troubleshooting

Minimum Version: 2.3.0 / 3.3.0


While FakeXrmEasy focuses on bringing as much of the development and testing experience closer to the devs and before deployment, you should be aware that there is a way to use FakeXrmEasy for integration testing as well.

Disclaimer: When you use a XrmRealContext class, it uses an actual connection string behind the scenes to connect to an actual real Dataverse instance so you should be very careful when usint it.

The benefit of using XrmRealContext might be identifying existing issues in a target environment that otherwise would be really difficult or impossible to reproduce locally, specially, when trying to understand or change an existing legacy codebase which didn’t have many unit tests…

When you use an XrmRealContext class you can trigger plugin executions but connected to a target instance. This means, unlike with unit testing, there is no middleware setup for integration tests, youl would, instead, directly create an instance of an XrmRealContext class with a connection string, and then use it to execute your plugin locally, but connected to a target instance. Be aware this would not be a real execution (as the plugin won’t be in the db transaction, for example), but it will allow you to step through the plugin code using live data at the very least.

There are many great resources by the community that explain XrmRealContext, feel free to check them out:

Replay plugin executions

If you use the Plugin profiler available in Plugin Registration you can also replay a previous plugin execution. You can grab the plugin execution context from the profiler, which is compressed, and copy & paste it into a method that will return an XrmFakedPluginExecutionContext ready to be used with the parameters that triggered that execution. If you then use an instance of XrmRealContext to call ExecutePluginWith() method passing in that plugin execution context, you’ll be able to replay the same execution against the target environment, but locally, with the same parameters the plugin received when it was profiled.

You can see a sample of how to create an XrmFakedPluginExecutionContext from a compressed profile in this example.

Then execute that fake plugin execution context with an XrmRealContext (note how meta is the fact we used XrmFakedContext to mock XrmRealContext tests…. :) but, when replaying the plugin against a real instance you should really instantiate XrmRealContext with a connection string instead).