Archive · Week 15 · Apr 7 – 13, 2025from 2 items
The Go team accepted two proposals that will arrive in a future release. One adds a convenient way to store test artifacts, and the other introduces a helper method on `sync.WaitGroup` to launch goroutines that are automatically tracked.
Worth knowingstdlib
testing: store test artifacts
- What changed
- The
testing.TBinterface will get anArtifactDir() stringmethod, andgo testwill gain a-artifactsflag that causes the directory to be created under the test output directory. - Production impact
- The source does not say.
- Try it
- Run
go test -artifactson a package that writes files to the directory returned byt.ArtifactDir(). - Source
- github.com/golang/go/issues/71287
Explain it and run it
Understand it, then run it
The Go testing framework lets you write tests that can create temporary files. Until now, those files were deleted when the test finished, so you couldn’t keep them around to look at later. A new method, ArtifactDir, will be added to the testing.TB interface. When you run go test with the -artifacts flag, the method will give you a directory that lives under the test output folder and stays after the test ends. If you run tests without the flag, ArtifactDir still returns a temporary directory that is removed when the test completes, so existing tests keep working.
Run it now
// This program demonstrates how test artifacts are stored today.
// Since the proposed ArtifactDir method is not yet available in Go 1.27.1,
// tests use a temporary directory created with os.MkdirTemp, which is
// automatically removed when the test finishes. The program simply
// creates such a directory, prints its path, and deletes it.
package main
import (
"fmt"
"os"
)
func main() {
// Create a temporary directory for test artifacts.
dir, err := os.MkdirTemp("", "test-artifacts-")
if err != nil {
fmt.Println("error creating temp dir:", err)
return
}
// Ensure the directory is removed after use.
defer os.RemoveAll(dir)
// Print the directory path so a user can inspect it.
fmt.Println("Test artifact directory:", dir)
}
What it printed when we ran it on Go 1.27.1
Test artifact directory: /work/tmp/test-artifacts-2195789528
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.
Worth knowingstdlib
sync: add WaitGroup.Go
- What changed
- A
Go(f func())method is added tosync.WaitGroup. It startsfin a new goroutine and tracks it with the WaitGroup. - Production impact
- The source does not say.
- Try it
- Create a
sync.WaitGroup, callwg.Go(func(){…}), and thenwg.Wait(). - Source
- github.com/golang/go/issues/63796
Explain it and run it
Understand it, then run it
sync.WaitGroup is a type you use to wait for several goroutines to finish. Before the change you had to write three lines for each goroutine: wg.Add(1), start the goroutine with go, and inside the goroutine call defer wg.Done(). The new Go method lets you write a single line that both starts the goroutine and registers it with the wait group. This removes a small but common source of bugs where the counter is mis‑counted or the goroutine is forgotten.
Run it now
// This program demonstrates the new sync.WaitGroup.Go method.
// It prints the numbers 1 through 5 in parallel, each on its own line.
package main
import (
"fmt"
"sync"
)
func main() {
var wg sync.WaitGroup
for i := 1; i <= 5; i++ {
// Capture loop variable to avoid the classic loopvar bug.
i := i
// Start a goroutine that prints the number and signals completion.
wg.Go(func() {
fmt.Println(i)
})
}
// Wait for all goroutines to finish.
wg.Wait()
}
What it printed when we ran it on Go 1.27.1
1 3 2 4 5
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.
Exercise
Exercise
Use the new sync.WaitGroup.Go method to run several goroutines that compute the square of an integer and store the result in a map. After all goroutines finish, print the map. The map should be protected by a mutex.
package main
import (
"fmt"
"sync"
)
func main() {
var wg sync.WaitGroup
// TODO: use wg.Go to launch goroutines that compute squares
// and store them in the map.
// Wait for all goroutines to finish and then print the map.
}
Show a solution
package main
import (
"fmt"
"sync"
)
func main() {
var wg sync.WaitGroup
mu := sync.Mutex{}
results := make(map[int]int)
// Numbers to square
nums := []int{1, 2, 3, 4, 5}
for _, n := range nums {
// Capture n for the goroutine
n := n
wg.Go(func() {
square := n * n
mu.Lock()
results[n] = square
mu.Unlock()
})
}
// Wait for all goroutines to finish
wg.Wait()
// Print the results map
fmt.Println("Squares:", results)
}
What it printed when we ran it on Go 1.27.1
Squares: map[1:1 2:4 3:9 4:16 5:25]
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.
The 60-second version
This week the Go team added two new features that will arrive in a future release. First, the testing package now has an `ArtifactDir` method on `testing.TB`. When you run `go test` with the `-artifacts` flag, the test framework will give you a dedicated directory to store any files you need to keep for debugging or analysis. The directory is unique per test or subtest and lives under the test output directory, so you can safely inspect it after the test finishes. Second, the `sync.WaitGroup` type now has a `Go` method. Instead of manually calling `Add(1)` and launching a goroutine, you can simply write `wg.Go(func(){…})`. The method starts the goroutine and automatically tracks it, simplifying parallel code and reducing the chance of forgetting to decrement the counter. Both changes are marked as “Worth knowing” because they change how you write tests and concurrent code, but they do not break existing programs.
Written by gpt-oss-20b · claims checked against the sources · archive, not individually reviewed