Testing distributed services is hard. Troubleshooting test failures is challenging when the failure isn’t from the immediate service under test, but from another dependent service.
One way to ease troubleshooting test failures is by using tracing. Tracing can help see the flow of requests between tests and services.
Gomega is a Go assertion library commonly used with Ginkgo. Out of the box, Gomega has pretty solid formatting of values when assertions fail. Sometimes, we may know more about the value and how to better represent it in the output for easier test troubleshooting.
Several months ago, I started working on a Go linter (gomega-lint) for gomega. I’ve been using gomega at work for almost a year and love it now. I’ve formed some opinions on good practices for using gomega. But giving this kind of feedback during code reviews - it’s too late by that point.
You know that code that is tricky to unit test but easy to make an integration test for? And you track code coverage?
Well, the upcoming Go 1.20 release adds support for collecting code coverage from integration tests.
Go 1.20 has a new trick and can build binaries ready to collect coverage during integration tests.
In the same vein as the rest of my posts in the Container Networking series, I want to learn how Calico sets up pod routes between Kubernetes nodes.
If you log into a Kubernetes node using Calico and run ip route you’ll see something similar to: