Testing Concurrent Go Code

## Why a sleep is the wrong wait A Go test that does `go compute(); time.Sleep(50 * time.Millisecond); assert(...)` is not waiting for the goroutine — it is waiting for a duration and hoping the goroutine got there first. That has two independent defects, and both of them hurt. 1. **It is a guess about speed.** The 50 ms was measured on a developer laptop with an idle CPU. In CI the same test runs on a shared machine alongside a dozen other packages, the goroutine is descheduled, and the assertion fires before the value is written. That is the classic test that passes only because a sleep happened to be long enough on somebody's laptop, and it is the single largest source of a suite nobody trusts any more. 2. **It is dead time on every green run.** A hundred such tests, each sleeping 50 ms, is five seconds added to every single run, forever, even when everything works. Worse, a sleep gives you no *ordering* guarantee. Go's memory model does not say "a write becomes visible after 50 milliseconds"; it defines visibility through synchronising operations. Reading a variable the goroutine wrote, with nothing but a sleep in between, is an unsynchronised read even when it happens to return the right value. ## The signal, not the duration The fix is to make the goroutine *tell you* it is finished, over a channel: ```go done := make(chan struct{}) go func() { result = compute() close(done) }() <-done ``` `close(done)` is a good completion signal because every receiver of a closed channel is released and gets the zero value immediately — you can wait on it from several places, and closing is idempotent-looking to readers (though closing twice panics, so exactly one goroutine should own the close). Receiving from `done` blocks the test until the close actually happens: no earlier, no later. The wait now costs exactly what the work costs. When the goroutine produces a value rather than just finishing, send the value instead: ```go res := make(chan int, 1) go func() { res <- compute() }() got := <-res ``` ## Make the channel buffered when the test may give up Note the capacity of 1. If the test abandons the wait — because a deadline fired, or an earlier assertion failed the test — an *unbuffered* send has no receiver and the goroutine parks on it forever. That goroutine is now leaked for the rest of the test binary's life, holding whatever it captured. A buffer of one lets the goroutine deposit its value and exit even if nobody ever reads it. ## Always bound the wait A bare `<-done` turns a bug into a hang: if the goroutine deadlocks, the test does not fail, it stops, and you find out only when the whole test binary is killed by its timeout, long after the useful context is gone. Bound it: ```go select { case <-done: case <-time.After(2 * time.Second): t.Fatal("compute did not finish within 2s") } ``` The deadline is not a sleep in disguise, and the distinction matters: a sleep is on the *success* path and its length decides whether the test is correct; a `time.After` case is on the *failure* path and only decides how long you wait before declaring a hang. That is why it should be generous — seconds, not milliseconds. A tight deadline reintroduces exactly the machine-speed dependence you were removing. ## Do the asserting on the test goroutine Assert *after* the receive, in the test function itself. Reading `result` from the test goroutine after `<-done` is properly ordered, and any failure is reported by the goroutine the testing package expects to report it. Doing the assertion inside the spawned goroutine instead brings a separate hazard: the fail-fast methods of `testing.T` do not stop the test when called from another goroutine. ## The shape to remember Create the channel, close or send from the goroutine as its final act, receive in the test with a generous deadline case, then assert. Any test where you can point at a number of milliseconds and say "we hope it takes less than that" should be rewritten this way.