Skip to main content

Advanced testing of Golang applications

Golang has a nice built-in framework for testing production code and you can find many articles how to use it. In this blog post i don't want to talk too much about the basics, table driven testing,  how to generate code coverage or detect race conditions. I would like to share my personal experiences with real world scenario.

Go is a relative young and modern programming language on one side, and it is an old fashion procedural language on the other. You have to keep in mind that fact when you are writing production code from the beginning, otherwise your program should became an untestable mess so easily. In the procedural way your program is executed line by line and functions calls other functions without any control of the dependencies. Hard to unit test, because you are testing underlying functions too, which are side effects from the perspective of testing.  It looks like everything is static, if you are coming from object oriented world. There are no dependency injection frameworks and/or inversion of control  (of course you can implement them, if you want to abuse the language, but it's a different story). The $1000 question is how to write testable Go code, and Dependency Injection Design Pattern (DIDP) is the answer. What does it mean? You have to pass over all of your side effects as input parameter of the functions. Sounds trivial, but believe me it's tricky to solve on the nice way or so tiring to refactor the existing project later on.

Without applying DIDP the only proper way to test complex Go source is monkey patching. I found one library called monkey, to do this. I don't suggest to use it at all. Change running code on the fly is a bad practice from the view of testing. On the other hand i can imagine situations where there are no other options.

Let's see how DIDP works. In my first example i would like to open a file and than read the first byte of the file. It looks like something this (without any proper error handling, just keep it simple):

We have many options to reorganize the code to make it testable, and i would like to cover most of them later, but first let's see the easiest one. Functions are first class citizens in Go and our side effect is a function call above, so it is straightforward to pass the function as input variable:

Our new function doesn't know how to read a file, it gets  reader and the implementation is out of scope what causes very easy testing:

It's clear now what is DIDP (sorry for boring you), so time to talk about the options what we have in Go.

Mocks and fakes. Go has a few existing mocking framework and they have good integration with built-in framework. The reason why i don't like them is all depends on code generation, which requires an extra step in the development cycle. Here is a list of the most famous frameworks:
Functions and interfaces. As i mentioned functions are first class citizens and gladly Go has a really awesome dynamic interface implementation system. Why not use them? They don't require code generation, they are built-in, and we have full control of the behavior without replacing production code runtime. Function parameters are nice for simple features and interface parameters for the rest.

My example is part of a CLI tool. It retrieves a token, fetches a credential by name and prints the ID of the credential.

There are three side effects in the code.
  • Authentication process -> we simply move out of the implementation
  • CLI context argument finder (c.String) -> become function parameter
  • REST call to fetch credential -> become interface parameter

Let's write the test code:

In the previous solution we only tested the output of the function. What can we do if we are interested in for example the input parameter of the GetCredential() call? Things become a bit complicated at this point, but we can solve them by channels:

As you see built-in features of the language are enough to solve most of the cases, and not need to introduce external framework  into the project or increase the development process with extra steps.


Popular posts from this blog

Kubernetes and Calico development environment as easy as a flick

I became an active member of the Calico community so I had to built my own development environment from zero. It wasn't trivial for many reasons but mainly because I have MacOS on my machine and not all of the features of Calico are available on my main operating system. The setup also makes some sense on Linux hosts, because if node controller runs locally it might make changes on the system, which always has some risk in the playing cards. The other big challenge was that I wanted to start any version of Kubernetes with the ability of do changes in it next to Calico. Exactly I had to prepare two tightly coupled environments. My idea was to create a virtual machine with Linux on it, configure development environments for both projects in the VM and use VSCode 's nice remote development feature for code editing. In this way projects are hosted on the target operating system, I don't risk my system, I don't have to deal with poor file system sync between host and g

How to sign messages in Java and verify in Go

In my company we use Java and Go as our development platforms and of course sometimes those projects has to communicate with each other. In the current blog post i would like to introduce our solution to sign messages on the Java side and verify them in a Go service. First let's talk a bit about the architecture. Our Java application spins up new virtual machines in the cloud, and the base image of the instance contains a small Go service. That service is the main entry point of our configuration management system, and we don't want to allow any operation from untrusted clients to modify nodes. Two way SSL with a signature in the request sounded fair enough to trust in clients. Both components are open source, we don't have any "secret" in the binaries, so we elected RSA asymmetric key pairs to generate and verify signatures. Java has the private key and Go has the public one. Time to go deeper. Java is an old platform (personally i have many years of experie

First impressions of the new Cloud Native programming language Ballerina

Nowadays everything is Cloud Native; everybody talks about CN tools, frameworks, solutions, and so on. On the other hand those tools totally changed the way we design, develop, test and release modern applications. I think the number of issues which we solved with the new concepts is equal with the number of new challenges, so in short we simply shoveled problems from one hole to the other. Many new tools appeared on the market to make developers' life easier by integrating software with the underlying infrastructure watching file changes and building containers automatically generating resource descriptors on the fly allowing debugging in a running container etc. Next to the new tools, new programming languages such as Metaparticle , Pulumi or Ballerina have been born. The last one had my attention because others are extensions on top of some existing languages, while Ballerina is a brand new programming language, designed fro