Share on facebook
Share on twitter
Share on linkedin
Share on whatsapp
xnegra.png

Create Unit Tests in GO, Step by Step

Here we explore how to perform the tests with the testing package that comes installed with GO, and with a framework that should make the process simpler. We are also going to work with white box and black box testing.
Unit Tests in GO

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

Should we test our code? I don’t think we even need to ask that question, in my opinion all our code should be tested.

Leaving that behind, let’s move on to the important aspects of GO.

First of all, it is important to point out that in GO there is no test framework like in xUnit, NUnit, MSTest (C #), or JUnit (Java).

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.

Sounds like a good idea, right? So let’s use this example to delve a little deeper. The goal of our project is to test a high percentage of our code, and in order to reach our goal we will take the services of the CRUD operations and apply white box and black box tests to increase our “coverage”.

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

As for the methods in GO, the tests must respect the following signature “TestName(t*testing.T)”, ie. the word Test followed by a meaningful Name, and we need to use *testing.T, which is our helper, as a parameter.
With this in mind we can now run our test.

Project structure:

Go-Reset API

Cases 1 and 2 of Testing in GO

Go-Reset API 2
Using the Given, When, Then structure, we declare the values we expect to obtain, and also instantiate our service, call the method to be tested, and evaluate the expected results. If we run the following test, we get:
Go-Reset API 3
If we change one of the expected values ​​and run it again we get:
Go-Reset API 4

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.

Go-Reset API 5
As for black box tests, they do not belong to the package that we are testing, therefore, the way to accomplish this is to simply create them within another package:
Go-Reset API 6
As the image shows, the test was created within the package “deleting_test”, making it a black box test, which indicates that we do not have access to the internal methods of the package, and that we must indicate each reference with its package. For example, if we want to access the Student struct in the deleting package, we must do so like this: deleting.Student
Go-Reset API 7

GO Test Case # 3

Testify is a set of tools that helps us perform unit tests simply. Among its tools we can find:

This would be our test without using the toolkit:
Go-Reset API 9
And this would be the same test using Testify’s assert tool
As you can see, although the change does not seem like much in principle, when we have many assert cases, it would be advantageous to change 3 lines of code for 1.

Bonus

Another interesting topic is “Immediate Failure” and “Non-immediate Failure”. The former is used when we want to cut the execution of test cases, for example, if we need to access a DB, or need to use a file that does not exist, then we cannot continue testing (assuming that proving the existence of said resource is not the objective of the test).
The latter, on the other hand, is used when we want to report a failure, but we want to continue testing, for example, when a record has been inserted, but the ID has been miscalculated.
Immediate Failure:
Non-immediate Failure:

Bonus # 2

The differences between white box and black box:

In closing, I hope I have managed to give a general overview of how to perform unit tests in a project in GO.

There is still much more to develop, such as integration tests, table-value tests, and coverage tests, etc.

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.

Mauricio Bergallo

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.

Don't forget to share this post!

Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on whatsapp
Share on print

SAN DIEGO

6790 Embarcadero Lane Suite 100
Carlsbad, CA 92011, USA
+1 (888) 622-7098

MIAMI

1951 NW 7th Ave #600
Miami, FL
33136, USA
+1 (888) 622-7098

CÓRDOBA

Velez Sarsfield 576
Cordoba, Argentina X5000CCD
+54 (351) 426-5110

LIMA

Jiron Colina 107
Barranco, Lima CP 04, perÚ
+51 (1) 248-8687

MEDELLÍN

Calle 29 #41 – 105
Edificio Soho
El Poblado, Medellin COLOMBIA
+57 (4) 403-1770

©Santex 2019. All rights reserved.