The first few steps of this recipe focused on setting up our unit test class. In step 6, we declared the classes we are mocking as private instance variables. Note how we only used interfaces as we don't really care about their concrete implementations; we focused on their signatures.

In step 7, we defined the stubs and mocks of our data access layer classes. IEmailDataAccessLayer gets its GetEmails method mocked; given any GUID input, the method returns three e-mails; two with a subject and one without. We then stubbed ICustomTracingService to provide us with an empty Trace method.

In step 8, we build our unit test. Unit tests are targeted tests. This test only focuses on the UpdateEmailLogic method and its behavior. We started by arranging our test, by instantiating UpdateEmailLogic and injecting the mocked and stubbed classes in its constructor, leveraging the dependency injection pattern we introduced in Refactoring your plugin using a three-layer pattern earlier in this chapter. We then acted and called the business logic's UpdateAccountsEmails with a randomly generated GUID. In the last steps, we asserted that the CloseEmailAsCancelled stubbed method is called exactly once, and the UpdateEntity method is called exactly two times as expected, based on the mock GetEmails returned objects. We also verify that the Trace method is called once with the correct message parameter.