Every time I write tests in my Go projects, I use code coverage to be completely sure I don’t skip important parts that I intended to test. For viewing the reports, depending on the situation, I use either the built-in coverage reports in Neovim (powered by vim-go plugin), or for more complex cases – gocovsh.

Gnomock had a very extensive test suite since the very beginning. The tests ran on Github Actions and CircleCI platforms, on Linux, to make sure that both CI/CD platforms are properly supported. After all, Gnomock is used during CI, and not only locally.

A recent Gnomock release v0.10.0 brought a new integration with it: k3s preset that allows integration testing of Kubernetes automation tools written in Go. This new preset creates a docker container that runs a single node k3s (lightweight Kubernetes) cluster in it. It uses orlangure/k3s docker image that has many k3s versions available as tags.

Kafka message broker is a popular choice for Go programs that require high performance and great scalability. In this post I’m going to demonstrate an easy way to build integration tests for such applications. These tests won’t need any mocks: they use a real Kafka instance under the hood, giving the most confidence that everything works correctly.

I like writing integration tests for my Go code. They give me confidence that everything works as expected. This was one of the reasons I built Gnomock (an integration and end-to-end toolkit based on Docker): to easily write tests for code that uses databases or other external services, like AWS S3 or Splunk.

A few months ago I built gompress: a simple utility that takes a location in AWS S3, compresses all the files in it with GZIP, and puts them in another location, also in S3, optionally keeping or removing the original files. It was something I wrote to use once on a large S3 bucket full of uncompressed CSV files, and published it for anyone else who might need it.

I recently added a new feature to Gnomock: an option to forward docker container logs to a user-provided io.Writer implementation. In short, Gnomock spins up popular tools inside temporary docker containers and allows Go applications to run tests against them very easily. Each supported 3rd party tool is a Preset, and anybody can implement any preset they want.

Some time ago I worked on a very interesting project, which was a bit different from all the other things a was used to do. It was about migrating our production database from a standalone self-hosted MongoDB instance to one of the cloud providers.

How many times did you find yourself in an argument about whether or not a certain detail in some programming language or framework was implemented in a certain way? I’m talking about questions like these ones: Can a JS promise be rejected after resolution?

I have a friend who happens to be a huge fan of Apple products. He also hates Vim. He has quite a few stories about how awful Vim is, and how many problems it causes. A few weeks ago he texted me about a weird problem he had with editing a file on a remote server using Vim.