Software developer. Maintainer of Gnomock. Sometimes I write about the tech I use. Opinions are personal.
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.
We used PhantomJS for automated UI testing for some time. It successfully helped us to be sure that our Polymer-component based pages behaved correctly. At least that’s what we thought. We used Mocha for testing with mocha-phantomjs package. Our tests looked pretty much the same: we created some components, triggered events and evaluated the results.
I love learning new stuff. There are tons of things I’d like to read, understand and remember. I’m sure such attitude helps me to constantly improve myself and grow professionally. A lot of developers share my point of view, and these who don’t, probably should.