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 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.

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 are probably going to simplify your life right away.

Again in this article, you have 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 me through 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 starts being useful and solving some actual use cases, you realize that the quality of your code 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.

This is the last article of a series on taking notes. In the previous ones, I shared the reasons why I think taking notes is useful as well as some of the things that I do when I take my notes. This article contains ways of making use of the effort that we have put into writing those notes. Some of them are specifically geared toward digital notes and won't be very useful for handwritten notes, but there is one which applies only to notes on paper. 😉