你正在使用哪个版本的Go( go version
)?
$ go version
go version go1.16beta1 linux/amd64
这个问题在最新版本中是否重现?
是的
你正在使用什么操作系统和处理器架构( go env
)?
go env
输出
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN="/home/leighmcculloch/local/bin"
GOCACHE="/home/leighmcculloch/.cache/go-build"
GOENV="/home/leighmcculloch/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/leighmcculloch/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/leighmcculloch/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/leighmcculloch/local/bin/go/1.16beta1"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/leighmcculloch/local/bin/go/1.16beta1/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.16beta1"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/leighmcculloch/devel/gas/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build3757789103=/tmp/go-build -gno-record-gcc-switches"
你做了什么?
运行go测试。
go test
你期望看到什么?
一个失败或通过的测试数量的计数。
你看到了什么?
只输出关于失败的测试,而不是失败或通过的数量。
功能请求
当我在一个涉及大量初始测试中断点的探索性功能上迭代时,看到进展是有帮助的。当我用Ruby编程时,我能看到通过/失败的测试数量,随着工作的进行,我看到失败的测试数量逐渐减少。更重要的是,当我调整代码时,如果我突然看到那个数字跳起来,我知道在尝试解决问题的过程中,我已经立即破坏了更多的东西。这不是一个关键的功能,但我认为它会有所帮助,因为我已经在其他地方发现了这个功能的用处。
我认为如果go测试输出最后包括以下测试数量的计数会很有帮助:
- 已执行的
- 已跳过的
- 通过的
- 失败的
我发现 gotestsum
以这种形式提供了失败测试的数量可见性:
DONE 10 tests, 9 failures in 0.833s
其他示例:
Ruby Rspec:
Finished in 0.00068 seconds (files took 0.30099 seconds to load)
10 examples, 3 failures
Ruby minitest:
Python unittest:
Ran 2 tests in 0.001s
FAILED (failures=1)
Rust:
test result: FAILED. 1 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out
8条答案
按热度按时间mfpqipee1#
这个输出是由什么消耗的?是否有可能工具会基于此构建,并期望输出稳定且可读?
ej83mcc02#
类似于 #30507 。
amrnrhlw3#
同时也是 #27755 和 #41748 的副本,后者被 #41878 取代(提议不再总是打印摘要,而是提供一个接口,让感兴趣的用户可以自己打印自定义统计数据)。
00jrzges4#
这个输出是由什么消耗的?工具是否会基于此构建并期望输出稳定且可读?
@davecheney 我指的是针对人类的go test输出,而不是针对机器的
go test -json
输出。机器可能已经从现有的JSON输出中提取了这些信息。类似于#30507。
类似但不同。那个问题关注的是整体的失败/通过指示器。这个问题关注的是测试通过/失败计数。
这也是#27755和#41748的重复问题,后者被#41878取代。
#41878看起来是个很酷的想法,但解决的问题与我在这里提出的问题不同。它提供了自定义功能,我认为这个问题不需要自定义。#41748也是一个很酷的想法,但它提议在末尾打印测试名称,而不是计数汇总。
#27755看起来几乎就是我提议的。那个问题被关闭并锁定,几乎没有讨论。
在那个国家,@rsc表示:
如果你想构建替代显示,新的-json标志让程序消费测试结果并任意定制输出。这可能是正确的做法,而不是更改默认显示。
我建议的不是构建替代显示的功能,而是在默认输出中添加额外的日志信息,将通常包含在类似工具的测试输出中的信息暴露出来。我认为值得重新考虑这一点,可以作为#27755提出的每个包的计数,或者更简单地在末尾提供一个总结,这更常见,就像其他语言的测试工具一样。
y3bcpkx15#
/cc @bcmills@jayconrod@matloob
gupuwyp26#
gotestsum提供了这个摘要,例如:
看起来在#27755上已经就这个问题做出了决定。
gotestsum
是推荐解决方案的一个例子。2g32fytz7#
我们对运行次数、传球次数和失败次数感兴趣。我们有一个包含数百个测试的项目,需要某种形式的测试结果汇总。这是为了向上级报告我们的产品状态或一目了然地报告测试覆盖率。目前正在尝试使用PowerShell Core聚合测试运行的输出行,使用以下代码(Select-String类似于grep):
从上面的内容来看,
$runs != $passes + $failures
。因此,按用户进行聚合是很困难的,因为我们不知道Golang如何决定输出这些行。nimxete28#
如果你只是想快速找到一个解决方法来查看测试的通过率,就像我一样,你可以使用
jq
,如下所示: