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.
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?