Go版本
go版本 go1.22.1 darwin/arm64
在你的模块/工作区中的go env
的输出:
GO111MODULE=''
GOARCH='arm64'
GOBIN=''
GOCACHE='/Users/spike/Library/Caches/go-build'
GOENV='/Users/spike/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/spike/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/spike/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/opt/homebrew/Cellar/go/1.22.1/libexec'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/opt/homebrew/Cellar/go/1.22.1/libexec/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.22.1'
GCCGO='gccgo'
AR='ar'
CC='cc'
CXX='c++'
CGO_ENABLED='1'
GOMOD='/dev/null'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/53/zffdtv3x7lg_pyhrk85p7_nw0000gn/T/go-build3395173330=/tmp/go-build -gno-record-gcc-switches -fno-common'
你做了什么?
自从升级到macOS 14.4,我注意到了这种行为。我不认为在macOS 14.2中存在这个问题。如果我有一个测试用例启动一个进程,然后向它发送一个 SIGINT
信号,如果通过test2json运行测试用例,信号将不会被传递。如果直接通过 go test
或直接执行测试二进制文件运行,信号会被传递。
以下是一个最小的测试用例,可以重现这种行为:
package execsigs
import (
"errors"
"os"
"os/exec"
"testing"
)
func TestSigInt(t *testing.T) {
cmd := exec.Command("sleep", "10")
err := cmd.Start()
if err != nil {
t.Fatal(err.Error())
}
err = cmd.Process.Signal(os.Interrupt)
if err != nil {
t.Fatal(err.Error())
}
err = cmd.Wait()
var exitErr *exec.ExitError
if !errors.As(err, &exitErr) {
t.Fail()
}
}
你看到了什么发生?
如果我通过 go test
运行这个测试,或者创建一个二进制文件并运行它,它会通过:
spike@Codebook execsigs % go test -v execsigs_test.go
=== RUN TestSigInt
--- PASS: TestSigInt (0.00s)
PASS
ok command-line-arguments 0.833s
spike@Codebook execsigs % go test -c -o test execsigs_test.go
spike@Codebook execsigs % ./test -test.v
=== RUN TestSigInt
--- PASS: TestSigInt (0.00s)
PASS
但是如果我通过 test2json
运行,它会失败。SIGINT没有传递给 sleep
,所以测试不是以错误结束,而是花了10秒钟,进程干净地退出。
spike@Codebook execsigs % go tool test2json ./test -test.v=test2json
{"Action":"start"}
{"Action":"run","Test":"TestSigInt"}
{"Action":"output","Test":"TestSigInt","Output":"=== RUN TestSigInt\n"}
{"Action":"output","Test":"TestSigInt","Output":"--- FAIL: TestSigInt (10.01s)\n"}
{"Action":"fail","Test":"TestSigInt"}
{"Action":"output","Output":"FAIL\n"}
{"Action":"fail"}
你期望看到什么?
测试的结果应该与 test2json
相同,即在测试过程中向进程传递SIGINT。
这很烦人,因为像GoLand这样的IDE依赖于 test2json
在底层执行go测试。
3条答案
按热度按时间zazmityj1#
重复的#54023
isr3a4wc2#
这不是关于#54023的重复问题,该问题似乎与
test2json
是否处理发送给它的信号有关。这个问题是关于单元测试能否成功地向由测试创建的第三个进程发送信号。r7s23pms3#
好的,我明白了。
我认为这来自CL 419295,用于#53563。