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 log, write to a buffer (Error/f, Fatal/f, Log/f, Skip/f) - the calls can be made into slog records, even (2) slog.Handler methods write to the same buffer - so, the instance can just be passed to some code under test that slogs (3) the buffer dumps to test output when a test failure with Error/f or Fatal/f is seen If the goal is getting a nice sequence of just the relevant log lines leading to a test failure, this is feasible for independently executing tests. If there is crosstalk between parallel tests, this isn't sufficient - structured logging maybe makes the problem easier but it's not trivial. On Monday, March 13, 2023 at 8:23:10 AM UTC-7 Patrick Ohly wrote: > > 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 problem is that every single test needs to be modified for it to work. > I was hoping to avoid that for `t.Error`, but given the reactions so far, > that's probably what we'll have to do. Perhaps I'll write a code generator > which wraps `KTestFoo([ctx *context.Context, ]t testing.TB)` in a generated > `TestFoo(t *testing.T)`. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/4801e6f7-0dc3-4d3c-96fa-ab9123944ec0n%40googlegroups.com.
