Radar · Go · Archive · Week 35 · Aug 25 – 31, 2025

Testing Time (and other asynchronicities)

Nice to knowtooling

What changed: The blog discusses testing asynchronous code and introduces the testing/synctest package.
Production impact: The source does not say.
Try it: Read the blog and experiment with testing/synctest in a small Go program.
Source: go.dev/blog/testing-time

Understand it, then run it

Testing code that runs in the background can feel like a guessing game. You call a function, it returns immediately, and then somewhere else in the program it does something. If you want to make sure that thing happened, you have to wait for it, but you don’t know exactly how long to wait. The new testing/synctest package in Go 1.24 was created to make that waiting easier. It lets a test “observe” when the background work is finished without having to guess or sleep for a fixed time.

Run it now

Todaygo

// This program demonstrates the current way to test asynchronous code
// without the new testing/synctest package.  It starts a goroutine that
// sleeps for 100 milliseconds and then signals completion on a channel.
// The test waits on that channel instead of sleeping for a fixed time.
package main

import (
	"fmt"
	"time"
)

func main() {
	done := make(chan struct{})

	// Start a background task that will finish after 100ms.
	go func() {
		time.Sleep(100 * time.Millisecond)
		close(done)
	}()

	// Wait for the background task to finish.
	<-done
	fmt.Println("Background work completed")
}

What it printed when we ran it on Go 1.27.1

Background work completed

Run sends this program (for Solidity, the contract and its tests) to our own sandbox, where it is compiled and run once, with no network, and what it printed or the test report comes back here. Nothing is kept. Runs are counted per visitor for the day so everyone gets a turn; the details are on the legal page.

Written by gpt-oss-20b from the linked source · claims checked against the sources · archive, not individually reviewed