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 webOS¹ 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 scenarios where things don't go as expected, and still have our program react properly. We should also test for these situations, and those tests are as important as the ones that check the successful use cases.

Now that we understand the building blocks for writing unit tests in Rust, you probably feel the urge to apply that knowledge and fully cover your application with tests. Don't you? Well, I would ask you to hold your horses and apply it gradually. We still have a lot of ground to cover, but the next sections will probably simplify your life right away.

Again, in this article, you'll find the final version of the supervillain.rs file at the bottom, and the repo with the incremental commits is available here. In case of doubt, check the code or feel free to reach out to me on any of my social media accounts.

So, you have finally learned Rust and are writing cool projects with it. Awesome! However, as soon as your project becomes useful and solves real use cases, you realize that code quality is important. Not only that. The larger and more complex your project becomes, the harder it is to manually test every bit of functionality after a change.

Your first temptation might be: "Why should I test everything if my changes only affect this small part of the program?" And, while in some situations that might be true, more often than not, our changes affect unexpected parts of our program.