> Associate with the context a Logger that goes to T.Log?
That is indeed the approach taken in
https://pkg.go.dev/k8s.io/klog/v2/ktesting for contextual logging with
go-logr.
https://pkg.go.dev/golang.org/x/exp/slog doesn't have anything for it at
the moment, at least not out-of-the-box.
The
The underlying problem is that a "go test" only has one output stream: the
text written via `T.Log`. Additional output on stdout or stderr isn't
associated with the test that produced it, which is bad when running tests
in parallel or when running without "go test -v".
Sean Liao schrieb am
"-v" only changes how the result is presented. It doesn't change the result
itself, i.e. it remains unclear which log message indicates the actual
failure inside the test.
Jason E. Aten schrieb am Freitag, 10. März 2023 um 11:28:56 UTC+1:
> Perhaps the -v flag to "go test" would be helpful
JSON output doesn't help. There's no indication there either that a certain
message is a test failure. That's because t.Error = t.Log + t.Fail.
Attached is an example.
Bye, Patrick
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To
Hello!
In Kubernetes, we have extensive infrastructure for collecting test
failures. For "go test" based tests (unit tests, integration tests) we use
gotest.tools/gotestsum to convert the output to a JUnit file for
post-processing.
This approach has one drawback
Hello!
I'm working on logging in Kubernetes. One of the problems there is that all
log output goes through a global logger in the k8s.io/klog package, which
writes to stderr. When such code runs in a unit test, that additional
output is not associated with the currently running unit test, so
