Testing for Zombie Goroutines
Recently I have been working on some stage lighting control softeware, written in Go. In my tests, I spin up a websocket TCP server plus some workers that output lighting levels continously. I want to not only test to make sure that those parts work, but they also are stopped properly, after the test is over.
To deal with cancelation, I am using the awesome golang.org/x/net/context library. It has a couple of nice features, but here I am only using the
context.WithCancel function to get a cancel function, that I use after testing to cleanup.
Using GoConvey for testing, the setup would look something like this:
Here is the interesting function,
As you can see, this is a pretty hacky/horrible way of checking whether we have any zombie goroutines left running. It just basically searches for a line in the whole stacktrace that points to a file in your module, that isn’t a test file.
At first I thought I could just check whether there were more than on goroutine running, because I assumed the test would use one goroutine, so if there were any other left over, after I cancelled, then I should assume it was my fault. However, I found that there were often multiple testing goroutines running at once.
Another options is just to not care if you leave any zombie goroutine around, since they don’t use that much memory. I wanted to care, however, since some of my gourtines had had effects (opening up files or serial ports), so I wanted to make sure they died when I told them too.
I am, however, very new at Go. So I am most likely thinking about this whole problem wrong. If you agree, please comment or let me know where my thinking has gone astray. I will also be at GopherCon this week and would love to talk.
This post was inspired by Peter Bourgon’s great talk, which asked the Go community to talk more about their approaches to using the