Re: [golang/go] proposal: testing/synctest: new package for testing concurrent code (Issue #67434)

DRANK

spenczar left a comment (golang/go#67434) I have found `synctest` completely delightful. It has solved real problems for me, and helped me find bugs. My system has workers in separate processes which coordinate to allocate work. When a worker joins, a rebalance procedure takes place to reallocate work. Before synctest, this was very hard to test with `go test`. I had to reach deep into the coordination internals to set up hook points, using channels to imitate a kind of synchronization. But then I had to check those channels with timeouts, and things were flaky. Synctest has made my tests very reliable. I was surprised at how much _simpler_ it has made my tests, too. Gone are the callbacks and hooks and `select`s to check if a signal channel has closed within a timeout; now I can just `synctest.Wait()` for things to settle, and it all kind of works. Two things that gave me (very minor!) difficulty: 1. My test leaked a goroutine, and thus didn't terminate. I spent a long time barking up wrong trees on this. I should have read the documentation more closely. I suppose I came in thinking synctest is about synchronization, and not about goroutine leaks. 2. I found it tempting to sprinkle `synctest.Wait()` all over the place. I wish I had a way to know which of my `synctest.Wait()` calls were pointless. If the bubble root's goroutine is the only goroutine that has advanced between two `synctest.Wait()` calls, maybe I should get a stern warning of some kind. Overall, I immediately feel like synctest is something I will want to reach for and use to improve many concurrent tests. This is great! -- Reply to this email directly or view it on GitHub: https://github.com/golang/go/issues/67434#issuecomment-2837538884 You are receiving this because you are subscribed to this thread. Message ID: <golang/go/issues/67434/2837538884@github.com>