Making your Go service testable requires dedication from the very first minute of its existence. To turn an old service testable, while is not impossible, is a harder task. So be sure to have testing in your mind (always, not just in Go) before you start coding.
Testing usually comes with mocking holding its hand. Mocking functions, services and stuff in Go relies heavily on interfaces. We’ll talk about tools later on but at least the two most used rely on implementing the interface you want to test and do checking on it’s parameters and return values.
So, the rule…
Over the last few months I’ve been doing some deeper research over some topics about Go that I found interesting and wanted to have a deeper knowledge about. While probably most people that have known the language for quite some time already know these topics, there are always newcomers who this might help. So instead of keeping my notes to myself I’m making them public.
Have you ever heard the tale of Peter, the young shepherd? Every once in a while Peter cried for help because the wolf was coming and the town would go into his rescue, only to find out he was lying. The one time the wolf really appeared no one answered Peter’s call. They had lost confidence in him.
One of the most important things about alerts is confidence. You should be confident that when they sound it’s because something is really happening, and when they are not, everything it’s ok.
At my current work at peya-tech we’ve been using a combined forces architecture for the last 6 months that has worked quite well so far. It consists of a mixture between the concepts of Clean Architecture and Domain Driven Design.
You can find plenty of information of both concepts around, there are great books explaining these topics and other sources. We’ll leave you some sources at the end of this article.
To set us in motion, The Clean Architecture first introduced by Robert C. Martin (aka Uncle Bob) defines an architecture for your software project that separates each layer according…