I am a big proponent of using unit testing to keep the API stable and robust for your users. But I get smart about how I use my unit tests and what I’m testing. My philosophy is that you should only unit test your project as much as necessary. What I mean? I can get a lot of angry comments for this point of view, but I’m not too concerned about 100% test coverage. Do I think we need tests that cover important parts of the API and isolate each area independently to ensure that the contract of each code segment is honored? Sure! This is exactly how I do it and what I want to discuss.
Since our demo project Chinook.API is very lightweight, and integration testing can be done for it (more on that later), I found myself concentrating most on unit tests in my Domain and Data projects. I will not go into details on how you should unit test (since that is beyond the scope of this article). I want you to test as many of your Domain and Data projects as possible using data that is independent of your production database. This is the next topic we’ll cover, called Data and Object Mocks.
Why use data / object mocks in your unit tests?
We looked at what and why we need for unit testing. It is also important to understand how to properly unit test your ASP.NET Core Web API code. Data is the key to testing your API. You need to have a predictable dataset that you can test. This is why I would not recommend using production data or any data that may change over time without your knowledge. We need a stable dataset to ensure that all unit tests are running and validate the contract between the code segment and the test. As an example, when I test the Chinook.Domain project to get an Album with ID 42, I want to be sure that it exists and has the details expected from it, such as the album name, and is associated with an Artist. I also want to make sure that when I get a set of albums from the data source, I get the expected shape and size that matches the unit test I wrote.
Many colleagues use the term mocks to refer to this type of data. There are many ways to mock data for unit tests, and I hope you create as “real” a dataset as possible. The better your data you create for your tests, the better your test will be. I would advise you to first ensure that your data is free of privacy concerns and does not contain personal or confidential data of your company or your client.
To meet our need for clean, stable data, I create unique projects that encapsulate data mocks for my Unit Test projects. For the sake of clarity, let’s call my mocked project Chinook.MockData (as you can see in the original demo code). My MockData project is almost identical to my regular Chinook.Data project. It has the same number of data repositories and each one implements the same interfaces. I want the MockData project to be stored in a Dependency Injection (DI) container so that the Chinook.Domain project can use it in the same way as the Chinook.Data project connected to a production data source. This is why I love dependency injection. This allows me to switch Data projects in configuration without any code changes.
