Simple Unit Tests for Contoso Pizza Web Api - Tutorial and Demo
This tutorial and demo project will show how to set up, configure, and code simple unit tests for a WebApi project.
In this video, we will discuss how to write simple unit tests for a web API with CRUD controller operations. We will be using xUnit and FakeItEasy packages to write the tests. We will cover the basics of unit testing, including how to set up the test project, how to write tests for each CRUD operation, and how to use xUnit and FakeItEasy to create mocks and stubs. We will also discuss best practices for writing unit tests, such as keeping tests independent and ensuring that they are easy to read and maintain.
GitHub Project Repo
https://github.com/kathleenwest/Conto...
Project Series - Azure Virtual Machine Web App Demo (5 Episodes) See Link Below
• Swagger Documentation Tutorial
Script
In our unit test project, we use the following dependencies including xunit and fake it easy.
We are going to demo simple unit tests that follow the AAA pattern. Arrange. Act. Assert.
When writing a test case, be sure that you’re considering all possible scenarios that could occur in your code. This will help ensure that your code is robust and can handle a variety of inputs and outputs.
I recommend separate and organized unit tests covering class controllers, services, or models. To keep this project and demo simple, we are only going to demo and discuss unit tests for the main controller.
Here is a brief overview summary of complete and passing unit tests. These tests cover basic CRUD create, read, update, and delete operations in the controller. We also include unit tests for the patch operation.
The Get All or Read operation is easy to test as our code path is not prone to errors.
In our unit test code, we arranged and created a fake collection of pizzas. We created a test controller instance passing the same collection of pizzas that will be the in-memory data store. We then acted to get all the pizzas by calling the test controller method. Lastly, we asserted and verified that the collection of pizzas received matched what we originally passed into the in-memory data store.
The next controller method is Get by ID. There are three main code paths to plan unit tests including planning for bad user input, non-existent data, and the happy path.
Here is the unit test for the happy path. We arrange a test pizza in our collection with a pre-existing known identifier. The test controller is instantiated with the test pizza in the collection. We act to try and retrieve the pizza by the known identifier. We retrieve the result and assert that the identifier from the pizza retrieved matches the expected value.
Next, we look at the unit test for returning BadRequest when the user sends invalid input to the controller method. We test by sending invalid input and then verify the result matches the expected status code.
Next, we look at the unit test for returning NotFound when the user sends valid input to the controller method, but the identifier does not exist in the datastore. We test by sending a valid, non-existing identifier and then verify the result matches the expected status code.
The project unit tests with detailed comments are found on GitHub. So far, we have only discussed the Get or Read operations. But in the project repo, you can find additional unit tests for the create, update, delete, and patch controller operations.