In one of my previous posts I talked about what Happy path engineering is and how understanding the time to implement plays an important factor in that.
So, if time to implement is important how can we get better at estimating the time we need and how can we help others understand the benefits that estimates bring (and, the often, innacurate nature of them)?
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).
If you haven’t heard the term before it’s used to describe a user or system flow that goes through all the expected steps without any issues. Everything else is referred to as an edge case, or a state that the user or the system entered that was unexpected or unplanned, which may even trigger an error report.
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.
A couple of months ago I decided I wanted to learn a bit more about music so I decided to learn how to play the piano. This is an entirely new world for me, as I have practically zero prior knowledge. Little did I know then of how similar my experience was going to be to when I started writing code!
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 💪!