Microservices can also have bugs, so you have to be armed to handle all possible bugs. The first line of defense is unit testing.

Unit testing involves using HTTP clients to send an isolated request to a server or a request handler. In a unit test, you should check only one function. It's necessary to cover the majority of the code that helps to keep the same behavior of a function that can be reimplemented or improved with tests.

Also, you can write a test before writing any piece of code. It's called Test-Driven Development (TDD), but this approach is suitable for projects that have a good specification, because if you haven't decided on the solution, you will have to rewrite tests multiple times. In other words, TDD is not suitable for projects in which bugs are not critical, but where high-speed development is required.

Writing unit tests for traditional crates is simple, but for microservices, you have a lot of issues with emulating the environment in which a microservice will work in production. To emulate an environment, you can use mocking services that create HTTP servers with predefined responses for specified requests. Do you remember, in Chapter 11, Involving Concurrency with Actors and Actix Crate, when we created a routing microservice that we can't test, because we have to run a lot of microservices manually? In this section, we will create a unit test for that very routing microservice.