go cmd/test2json: tests 继承 signal.Ignore 来自 test2son

wkftcu5l  于 4个月前  发布在  Go
关注(0)|答案(3)|浏览(53)

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测试。

isr3a4wc

isr3a4wc2#

这不是关于#54023的重复问题,该问题似乎与test2json是否处理发送给它的信号有关。这个问题是关于单元测试能否成功地向由测试创建的第三个进程发送信号。

r7s23pms

r7s23pms3#

好的,我明白了。
我认为这来自CL 419295,用于#53563

相关问题