Mastering C# Unit Testing with Real-world Examples

Writing unit tests should be like telling a good story, with enough details to keep the story interesting but not too many to make it boring.

Use builder methods to reduce the "noise" and maintain the right level of detail in your tests.

This AccountController sends a welcome email to new clients after they sign up. That email contains a contact-us and other emails. This test validates that all those emails are present when creating an AccountController.

To keep reducing the noise in your tests, when working with the IOptions interface, use Options.Create() instead of a fake object with Moq.

Make the scenario under test obvious by initializing properties to the appropriate values. If you say something in a test name, make it easy to find inside the test.

Duplication is the root of all evil, even inside unit tests. To test the same method with multiple input values, use parameterized tests.

This PaymentRequestValidator, built using FluentValidation, checks that credit card expiration dates don't contain invalid months.

FluentValidation has helper methods for testing. Use them instead of directly asserting something on the result of TestValidate().

Instead of using loops to test the same method with various input values, use parameterized tests to avoid duplication.

When we can't use parameterized tests, our only option is to split a single test into multiple ones. Let's keep a single concern per test.

This PaymentProxy is a "client" service is responsible for taking payments from other modules within the system. It has a method called Capture() that expects a Deposit object.

To write more maintainable tests, avoid checking for exact matches of exception messages in your assertions. Any change in the punctuation, spelling, or structure of exception messages will make your tests fail.

Use object mothers to create test data. Using a dictionary and parameterized tests is hacky.

This ImportGuestsService validates that an uploaded file contains the required data.

Now it's your turn: your task is to refactor a test related to guest uploads. Pause the video and try to do it yourself. If you're stuck, there are some clues and a solution at the end.

Before refactoring tests that involve fakes, let's use a simple example to review what fakes are and differentiate between the two main types: stubs and mocks.

It's easy to create fakes by hand, but mocking libraries make things even easier. Let's explore one well-known mocking library: Moq. We're using Moq in the next lessons.

Make your test easier to follow by visually separating the Arrange, Act, and Assert parts of your tests. Instead of using vague terms, like "happy path" or "success," clearly state the scenario under test and the expected result.

This PayoutService feeds a payout report in Excel. It relies on an external payment gateway, such as Stripe, to display all transactions associated with payouts within a specified date range.

When dealing with multiple dependencies in the class being tested, using builders becomes tedious. Let's cover a simple alternative: TypeBuilder.

Remember that stubs are not the same as mocks. Let's stop asserting on stubs. When we do that, we're testing the mocking library, not our code.

Use simple test values to make your tests easier to follow. Do not overcomplicate things.

This DictionaryExtensions class contains a method that merges dictionaries.

It's your turn: refactor another test that involves merging dictionaries. Pause the video and try to do it yourself. If you're stuck, there are some clues and a solution at the end.

Avoid exposing private methods to test them directly. Instead, use public methods to test internal functionality. This is THE most common mistake when writing unit tests.

This SendEmailCommandHandler uses a repository to store emails, which are later sent behind the scenes.

Let's keep reducing the noise in our tests. This time, let's write a custom Verify() method for a mock.

Now it's your turn: Refactor a test that stores an email with duplicate addresses. Pause the video and try to do it yourself. If you're stuck, there are some clues.

Often, we bury assumptions inside builders, only to rely on those hidden assumptions throughout the rest of our tests. This practice makes our tests harder to follow. Let's make our assumptions explicit by creating a small domain-specific language in our tests.

This UpdateStatusCommandHandler uses webhooks or delivery notifications from a third-party email provider, such as Amazon SES, to update the statuses of stored emails.

Now it's your turn again: Refactor another test that updates an email status from a webhook. Pause the video and try to do it yourself. If you're stuck, there are some clues and a solution at the end.

If you have reached this point, congrats. I hope you have learned how to write readable and maintainable unit tests in C#. Let's summarize what we covered in this course.