Another byproduct of refactoring our code is rendering it unit-testing friendly. Separating the layers, especially the data access layer and the plugin entry, means that we now have a true business logic layer that is independent from connections to other systems. We can unit test this business logic as a standalone layer.

In our unit test, we will focus on behavior verification as opposed to state verification.

This unit test will not focus on the state of the records but rather verify that the correct methods were called the expected number of times and with the right parameters. We will follow the AAA pattern (Arrange, Act, Assert).

For a state verification unit test, look at the next recipe, Unit testing your plugin with in-memory context.

We will unit test the plugin business logic from the first recipe in this chapter. We will mock the IEmailDataAccessLayer DAL to return predefined values when the GetEmails method is called. We will stub ICustomTracingService as we don't really care about what it does. We only need to verify that the business logic calls it correctly and passes the correct parameters.