In the article introducing this series, I shared that I wanted to explore full-stack app development. In particular, I wanted to develop a full-stack application that helps people manage their checklists. Users will use a browser to connect to the front-end server, which, in turn, will use the API provided by the back-end server to access and modify the checklists.

This article is the first one describing what I am doing in Rust. I will cover project creation and structure, as well as build automation. We won't have much of the application implemented by the end of this article, but it should be a good and helpful start. So buckle up and let's get cracking!

In the article introducing this series, I shared that I wanted to explore full-stack app development. In particular, I wanted to develop a full-stack application that helps people manage their checklists. Users will use a browser to connect to the front-end server, which, in turn, will use the API provided by the back-end server to access and modify the checklists.

This article is the first one describing what I am doing in Java + Spring. I will cover project creation and structure, and build automation. We won't have much of the application implemented by the end of this article, but it should be a good and helpful start. So buckle up and let's get cracking!

In the article introducing this series, I shared that I wanted to explore full-stack app development. In particular, I wanted to develop a full-stack application that helps people manage their checklists. Users will use a browser to connect to the front-end server, which, in turn, will use the API provided by the back-end server to access and modify the checklists.

This article is the first one describing what I am doing in Go. I will cover project creation and structure, and build automation. We won't have much of the application implemented by the end of this article, but it should be a good and helpful start. So buckle up and let's get cracking!

In my previous articles, I have been writing about test doubles. I explained what they are and the different types we can use. I described some scenarios and wrote the test doubles that would help us test the code: dummies, stubs, spies, and mocks. Only one type was left: fakes. Let's look at those now.

Fakes are tests doubles that implement a simplified version of a task or computation. They come in handy when the real thing is slow or complicated. Ciphering messages is usually an expensive task, and we don't want our tests to take longer than they should. So, instead of performing the (real) encryption, we will have a fake that makes a simpler text manipulation.

This is the third article on test doubles. So far, I have covered stubs –that are used to control the responses to the methods of the type they double,– dummies –that fill "holes" that are required for some tests without any functionality,– and spies –that remember the interactions with the type they double. It is time to talk about the face of the band: mocks.

For the price of a mock, you get everything that was included in a stub and a spy, plus some intelligence. And I am not talking about AI. Mocks are a little smarter than stubs and spies, because they include the code to verify themselves. All those ugly asserts that used the fields in the guts of the spies will be no longer necessary.

In my last article, I explained what test doubles are and why we need them. In this one, I am going to focus on two different types of test doubles: the spy and the dummy.¹

A spy is a test double that remembers if its methods have been invoked and the arguments used with each invocation. It spies on the activity of the caller instance. A dummy does nothing, but it is required to create or use something else.

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 webOS¹ because of it being based on web development.