In the first few steps, we prepared our unit test class for our integration test. We declared the required using statements for the Dynamics 365 connection, the query libraries, and a reference to the CrmSvcUtil generated classes from our Packt.Xrm.Extensions project. We created some private variables to use across the class. In step 6 we instantiated a connection to our Dynamics 365 instance and assigned the organization service proxy to a local variable. We used the same pattern described in Connecting to Dynamics 365 from other systems using .NET recipe of Chapter 5, External Integration, and stored the connection in our unit test app.config (don't forget to replace the connection string with your instance's values). Be careful about exposing credentials' details in plain text. Unit tests are typically executed in low risk development environments; nonetheless, you should still follow best practices.

In step 7, we created a method that accepts some parameters to create an e-mail activity associated with an account.

Next we created a method to retrieve the e-mails to inspect them after we have updated the account. To retrieve the records, we are using the organization service Retrieve method. The Retrieve method takes a column set collection; in our example, we are only interested in the scheduled start date and the record's state. Alternatively, you can also replace the Retrieve method with a LINQ query that uses the organization context.

Step 7 and step 8, contain refactored code fragments that are used more than once in our core test method.

In step 9, we created a method that will help us with the arrangement of the unit test step. The method will create an account and associate three e-mails to it: two e-mails with a subject and one without a subject. The different e-mails cover the different expected scenarios when updating the account. Refer to the Create your first plugin recipe in Chapter 4, Server-Side Extensions, to understand the business logic behind the plugin we are testing. We retained the newly generated records' GUIDs to reuse in the assert step.

Finally, in step 10, we created the main test method that follows the AAA pattern. In the Arrange step, we created the account with the three e-mails attached to it. In the Act step, we updated the account. In the Assert step, we verified that two of the e-mails have an updated start date and that the third e-mail (the one without a subject) is now marked as cancelled. We marked the method with an integration test category attribute. This will help us filter integration tests that traverse the entire stack during ongoing unit tests and only keep them for nightly builds, or hourly rolling builds, due to their long execution time.