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.
This must be the most pervasive gotcha for people new to writing Ginkgo tests, but it definitely catches old hands from time to time. …
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: http://man7.org/linux/man-pages/man2/kill.2.html). …
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.
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
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