If this is the first time you come across the Go coverage profile then do read my last post: Test coverage in Go, working with packages and sub-packages. It is an introduction to Go’s cover tool, how to generate the coverage profile and how to use it to aggregate the coverage from the sub-packages to the root package.
If you are already familiar with the cover tool and the coverage profile then let’s dive in and see a few cases that you need to be aware of if you are trying to aggregate the coverage from the sub-packages all the way to the root of your package.
A test suite for any package is explicitly testing different code paths and identifies how your code works using different inputs. But does it actually manage to cover all the code branches that exist in your code? How about all the different functions?
One way to answer these questions is to thoroughly look at all the tests written (by you and your colleagues) and understand if there are any gaps. The easiest way to do that though is to use a tool, and in the case of Go this tool is called cover.
There is an excellent blog post on the Go Blog, called “The cover story” that describes how Go uses the cover tool to generate reports that I definitely recommend reading. In this post we are going to analyze a few parts of how the cover tool works and also provide a way to use it for packages which include sub-packages.
There are different ways of debugging a Go program. You could use print statements to view the values stored in your variables during the execution or you could use a debugger. Some IDEs, like GoLand, offer this functionality by default but it is also interesting to see how to use the integrated solutions from the command line. Delve offers both command line clients and an API that can be used to integrate it to other tools (which is actually what GoLand uses under the hood).
An Abstract Syntax Tree (AST) is a tree representation of the structure of a piece of code used mainly in compilers. ASTs can also allow us to traverse existing code and use the information collected to auto-generate new code, which we are going to do in this post! The structor is a command line utility we are going to build that given a domain package with struct definitions it automatically generates getter and setter functions for the fields of the structs.
Arrays and Slices are two of the most common data structures you will ever use if you program in Go. They share a lot of properties as slices are ultimately build on top of arrays but also quite different.
A simple definition of Go routines is found the “Tour of Go” section about concurrency:
a Go routine is a lightweight thread managed by the Go runtime
Now if you have not come across threads before, threads is a way for a program to run parts of itself in some sort of concurrent way. In this post we are going to examine the differences between running a program sequentially, using Go routines and Wait Groups and we are going to talk about thread safe access to a data structure. So… Let’s get started 💪!
A lot of things in life are a matter of perspective and visibility and the same applies to variables in Go 😅. But what is a variable’s scope, how is it defined and what does it mean to shadow a variable in Go?
Let’s (very) loosely say that the scope of a variable declares where this variable is visible from ie. if we have declared a variable at the top of the file then it’s visible from within the entire code of that file.
We can go even deeper than that though and we can break this question down into Go specific terms.
Go has its own package for handing sorting – called “sort” but in this post we are going to use the Go language to implement a sorting algorithm called Bubble sort.
Problem definition: Given a slice of integers sort them in ascending order
Bubble sort is an iterative comparison algorithm that sorts the elements by swapping them around if they are out of order. If a larger element comes before a smaller one => swap them and move on to the next position of the array.
Since version 1.7 the Go testing package provides the ability to run some of the tests in parallel (well not entirely in parallel but that is another blog post 😉). This is optional functionality you can enable by adding a single line of code t.Parallel() in your subtests. But how does that work exactly and what does Go actually do with these tests?
I find the way that strings have been implemented in Go to be really interesting but also a bit confusing when you are first introduced to them. Go has native UTF8 support, which flows through how the source code is written to how strings and “runes” are represented (runes is the thing that really got me by surprise but more on that later). So what does Go do differently with strings that is worth mentioning?