In my last post, I wrote about some effective Ginkgo and Gomega practices; there were a few more suggestions that came to mind as I was writing but they felt like they were less “effective” and more “where did the last three hours go debugging this crap?” — A fairly arbitrary distinction but it’s my post so…

Like the previous post, familiarity with Ginkgo and Gomega is expected before reading. With that in mind, here’s some pain-points you might want to take care to avoid when writing tests using Ginkgo and Gomega.

Not initialising a variable in the closest BeforeEach

This must be the most pervasive gotcha for people new to writing Ginkgo tests, but it definitely catches old hands from time to time. …

Image for post
Image for post

I’ve been writing Go tests using the Ginkgo BDD test library, and its preferred matcher library Gomega for almost four years as of writing. In that time I’ve discovered some recurring practices in the projects that I’ve joined, and in those I’ve started, which hopefully may be of use to you. I hesitate to refer to these as “Best Practices”, instead titling this post “Effective”, because although these work for me in most cases, they may not work for everyone in all cases.

Occasionally I’m going to link to codebases I’ve worked on recently that follows some of these practices, some of the time (hey, I said these weren’t best practices all the time!) …

If you write tests in Go, you may have come across the Gomega assertion library, Ginkgo’s preferred matcher. I’ve seen a few examples where engineers have written a convoluted series of assertions, when what they really wanted was a custom matcher to express intent.

I’ve spent the last few years working on the garden container manager for Cloud Foundry, Concourse and BOSH. Albeit trivial, it’s often useful to check whether a process with a certain pid exists or not, so let’s write a matcher for that!

Let’s start from a test that doesn’t have a custom pid matcher:

Ok so, it’s contrived, but in this test, we start a process that will sleep for 10 seconds, and then wait on it. We can then use the Consistently matcher to assert every second, for 5 seconds, that the process is still running (The 0 signal doesn’t actually send a signal but does do existence and permission checks: …

I’m a fan of Acceptance Test Driven Development, or Double-Loop TDD. This involves writing a failing high level end-to-end test that desires some feature, then following the red-green-refactor cycle through layers of unit tests until the acceptance test passes, and then repeating for the next feature.

Image for post

I’m also a fan of Go and CLI tools. No diagram necessary.

Given these statements, it’s important for me to able to write a test suite that will exercise my CLIs in a black-box manner. Even if you don’t write your tests first, it is still extremely important to have confidence that if you changed the internals (and you do refactor don’t you?!), …

Today’s post is brought to you by the letter Z.

Image for post
Image for post
Z for Zombies

This post is about Linux subreapers, why they exist, what their behaviour is, and how you can use them, via a practical example in Go. If you are comfortable with how the process table and process states work, you can go ahead and skip the preliminary reading section, otherwise let’s go!

Preliminary Reading on Process States

In Linux, a process can progress through various states, however, commonly when you look at ps output, you will only seeR (for running) andS (for interruptible sleep). …


William Martin

Software Engineer at Storyscript.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store