Before taking our first steps in creating unit tests in GO, it is important to bear in mind that in this article we are going to explain and present white box and black box tests. Before moving forward we recommend reading about GO – Rest API with DI.
Now, are you ready? Let’s start creating unit tests in GO.
Unit Tests in GO
Leaving that behind, let’s move on to the important aspects of GO.
Using standard GO code is always “recommended”. However, there are many good libraries that can assist us in writing unit tests quickly, and even intuitively, especially when the logic of our software is complex.
In this repository you can find the code from this article.
GO in a Real Case
To learn how to test with GO we are going to use a real-world example. In this article, we will be using the request of a client who wanted to build a web system for an educational establishment.
The first thing we need to do is explain the nomenclature and structure of the project. Since it is based on DDD, we will put our test cases in the same level or folder as the services, and the files must end in “_test.go” (due to a GO labeling issue).
Project structure:

Cases 1 and 2 of Testing in GO
- Case # 1: White box test with no additions (no external libraries, just standard GO code).



How do we create the SetUp and TearDown methods in GO? Well, there is a method called TestMain(m*testing.M) which will allow us to define the calls before and after the execution of the test.

- Case # 2: Black box test without additions.


GO Test Case # 3
- Black box test using Testify.
Testify is a set of tools that helps us perform unit tests simply. Among its tools we can find:
- Assertion, which gives us a simple tool to carry out validations without having to write the "ifs"
- Mockery, to "mock" the services, although we won't use them here since we are using dependency injection, and therefore don't need to mock any services
- Suite, which allows us to generate the test tools, and provides the BeforeEach, AfterEach, SetUp and TearDown methods (with other names, you can consult the API here). In this example, we do not need to use it as we have our DIY SetUp() and TearDown()


Bonus
Bonus # 2
- Firstly, being able to test each private method of the service (some will see this as an advantage, others as a disadvantage)
- Secondly, being able to import dependencies from other packages without falling into the circular reference problem, eg. if we are in the deleting package, and we import the storage package, which in turn imports the deleting package, then we have a circular reference problem
In closing, I hope I have managed to give a general overview of how to perform unit tests in a project in GO.
If you have read the previous article (and if you haven’t, I recommend that you do), you should have a pretty good idea of how to create high-quality, professional GO applications.

About the Author
Mauricio Bergallo is a Systems Engineer with extensive knowledge in a variety of programming languages. Great experience and understanding with all aspects of the software development life cycle.