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