Re: [go-nuts] "go test": common prefix for errors

2023-03-13 Thread Andrew Harris
I'm not sure I completely grasp the use case here in detail, but FWIW, I explored collation of log lines per-test with https://pkg.go.dev/golang.org/x/exp/slog a while ago and ended up with a struct that implements both testing.TB and slog.Handler. The idea was: (1) testing.TB methods that

Re: [go-nuts] "go test": common prefix for errors

2023-03-13 Thread 'Patrick Ohly' via golang-nuts
> 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

Re: [go-nuts] "go test": common prefix for errors

2023-03-13 Thread mspre...@gmail.com
With contextual logging, do we now have a better pattern easily available? Associate with the context a Logger that goes to T.Log? On Monday, March 13, 2023 at 5:00:51 AM UTC-4 Patrick Ohly wrote: > The underlying problem is that a "go test" only has one output stream: the > text written via

Re: [go-nuts] "go test": common prefix for errors

2023-03-13 Thread 'Patrick Ohly' via golang-nuts
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

Re: [go-nuts] "go test": common prefix for errors

2023-03-10 Thread 'Sean Liao' via golang-nuts
implementing a helper/wrapper on your side might be easier, I believe most helpers take the TB interface rather than the concrete T type. also it sounds more like a failure of the application to separate its output streams properly. -- You received this message because you are subscribed to the

Re: [go-nuts] "go test": common prefix for errors

2023-03-10 Thread 'Patrick Ohly' via golang-nuts
"-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

Re: [go-nuts] "go test": common prefix for errors

2023-03-10 Thread Jason E. Aten
Perhaps the -v flag to "go test" would be helpful here, as in "go test -v". On Friday, March 10, 2023 at 7:27:48 AM UTC Patrick Ohly wrote: > 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. >

Re: [go-nuts] "go test": common prefix for errors

2023-03-09 Thread 'Patrick Ohly' via golang-nuts
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

Re: [go-nuts] "go test": common prefix for errors

2023-03-09 Thread Ian Lance Taylor
On Thu, Mar 9, 2023 at 5:55 AM 'Patrick Ohly' via golang-nuts wrote: > > 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 >

[go-nuts] "go test": common prefix for errors

2023-03-09 Thread 'Patrick Ohly' via golang-nuts
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