When error messages contain “useful information” e.g. application-specific IDs or other variables then the error messages lose their “grepability”. In other words, you cannot quickly search a codebase for an error without removing anything you believe could be variable. You might not think this is a big issue, and I might even agree with you there, but you might as well make it a practice to make error messages boring – I.

Have you ever wondered how iota works in Go? Basically, iota is the index of the constant inside a multi-constant (const (...)) declaration. So the value of iota for the first constant is 0, the second constant is 1, and so on. This only works for constants, not vars. This is probably best explained with an example. package main import "fmt" type day int const ( // Start counting days from 1, so ignore 0.

This article will cover how to get visibility of your test coverage in Go. If you’re not comfortable with the basics of testing in Go, please checkout my earlier article aimed at beginners. Test coverage Test coverage gives you a high-level overview you how much of your production code was invoked in your tests (e.g. as a percentage), but it can also give you a lower-level view of exactly which lines are invoked or missed.

A while ago, I saw a question in a Go developer Slack channel that went something like this (translated): When would you want to define a function type like type MyFunc func(msg string) error? Do you have any examples? I replied with a http.HandlerFunc example (more on that below), but there were many developers smarter than me in that Slack channel, and I ended up learning a lot from the other answers to this question.

This past week I’ve had the privilege of having a Hack Week where I work, where we can work on whatever we wanted. I ended up building Mokku – a mocking framework for Go that gets out of your way. Key features Invisible: No hard (import) or soft (//go:generate) dependencies to add to your codebase. Unintrusive: Can be included in any developer’s workflow. Doesn’t dictate or enforce how you use it after it’s written.

Let’s have a go at writing tests in Go. Puns aside, testing in Go is baked into the language. Assuming you’re comfortable with the Go basics, let’s get started with writing tests. First of all, the way you run all tests in the current package is: $ go test However, unless you’ve got tests in your project nothing is going to execute. Go tests have to follow these three rules:

Today I released v1.0.0 of a Go package called jsonassert. It is my first self-motivated open source contribution that I think has a chance of being useful to someone other than just myself. Okay, that’s not quite true but it’s the first one I’ve written in Go. I realised the need for this package when attempting to increase the test confidence of a relatively untested package that sends JSON to a server.