This scenario showed a simple integration test that ensures that a synchronous plugin is doing its job. Asynchronous customization is harder to test as the time of execution is unknown and difficult to detect. You can introduce a wait condition, but that goes against best practices and is not reliable.

As we described throughout the recipe, clean code best practices also apply to unit tests. In this particular example we are only implementing one test. If you are planning on implementing several integration test classes, consider refactoring the code into class hierarchies. For example, create an abstract class that handles the Dynamics 365 connection and includes some reusable methods along with class structures to implement in child classes. At the end of the day, unit tests are C# classes and they will have to be reviewed, maintained, refactored, and updated over time.

One item that has been omitted from this recipe is the test's final tidying up. Best practice dictates deleting any record created specifically for the test. To clean up, you'll have to write a method decorated with a ClassCleanup attribute that will delete the created records. The GUID private variables have been initialized as nullable on purpose: in case the unit test fails at any stage, some of the GUIDs might remain null. Your cleanup method will check any non-null GUIDs and delete their corresponding records.