Unit testing is about writing tests for individual units (Duh!), most frequently these units are the types that we define in our code, i.e., structs / enums / unions, or first-class functions. But the types that we want to test usually have dependencies on other types and we would like to test them in isolation without having to worry about the details of those dependencies. That's why you need test doubles.
In my last article, I wrote about some builtin features of the tools that come with our Rust setup. They help you to produce better documentation, have more control of the tests you run, and debug tests/code when needed. The Rust ecosystem is very rich and active and people with other needs have contributed with really useful tools.
Today, I will write about two tools that might come in handy for you sooner or latter. There are many details in the following paragraphs, so fasten your USB-C cable and get ready!
As many other modern languages, regarding testing, Rust comes with batteries included. As you have seen in the previous articles of this series, you don't need to take any extra steps to be able to write and run unit tests for your code. It is clear where you have to put them, how to run them, and even cargo has a subcommand for finding and running them, and reporting the results. Could we ask for more?
I must confess. For many years, I have tried to avoid front-end web development by all means. I didn't want to touch it with a ten foot pole. And the main reason was because I have never felt comfortable with having to combine HTML, CSS and JavaScript with the nuances of each of the browsers to get the UI I wanted to produce.
When it came to develop user interfaces for my applications, I have preferred to use well established APIs. I started, looong ago, writing some small Windows applications, moved to X Window first and then to GTK, and after a while focused on mobile development. Even at that stage, I jumped from PalmOS to Android and iOS, almost skipping webOS1 because of it being based on web development.
So far, we have only tested synchronous code. I could postpone talking about asynchronous code, but I don't want you to wait for it. 😄
Asynchronous code, apart from being an inexhaustible source of dad jokes, can be painful to reason about its behavior and not always recommended. We tend to think that, in a given scope, the lines above are executed before the lines below. It really takes experience and discipline to realize that some parts of the code can be executed at a later time and that we may not have yet their results available. This is important when we write our asynchronous code, but even more when we debug it .
So far, we have chosen to test things that matched our expectations of how the code was supposed to work and how the user and the environment were supposed to behave. But, we should also plan for the scenarios in which things don't go as expected, and still we want our program to react properly. We should also test for these situations and those tests are as important as the ones that check the successful use cases.
