@jba

It's great that you're using slogtest and I would hate it if you had to stop using it because of this.

We can't change the package until the next release, and I don't see how we would change it for this. Maybe the function needs to take options like "I don't plan on displaying the time, ever." I don't want to do that, because every such option weakens the Handler contract. I'm open to other suggestions.

Anyway, you need a workaround for the next six months. Here are two ideas:

1. (very hacky) You know this is the n th test. That's not changing for at least six months. So you can hard-code your results function to skip the line that assigns to slog.TimeKey just for that test.
2. (less hacky) Add a testMode boolean to your handler, or as a global. When set, the handler follows the rules for time.

Hey @jba, thanks for the ideas on hacky solutions! I think both would work for this case. I was hoping to flag this before the release, but oh well.

For future consideration towards removing this test:

This test feels like an oddball of the current test suite. It's the only test that checks for a missing key on a non-attr property. As a result, the slog.TimeKey is the only key that's required to be rendered in some way by the resulting handler.

Some examples where this assumption breaks down:

• https://github.com/livebud/log: The console handler is the one that prompted this issue
• https://github.com/apex/log: The text and delta handlers show time as the delta from start and time in-between logs. I don't think these log handlers would work either.

Thanks @matthewmueller, I'll think on it.

/cc @ianthehat

Change https://go.dev/cl/516076 mentions this issue: testing/slogtest: add Run to run cases as subtests

Maybe the function needs to take options like "I don't plan on displaying the time, ever." I don't want to do that, because every such option weakens the Handler contract. I'm open to other suggestions.

I do not have suggestions, I just want to note a use case I ran into that proved to be hard to test with slogtest.
I wanted to create a Handler that wraps slog.JSONHandler and only logs errors(slog.LevelError). The actual usecase is a bit more involved but the minimized description and repro is enough to show the issue.
Link to playground; https://go.dev/play/p/OUVqbIUeKc4

// errHandler wraps [slog.JSONHandler] to only log errors.
type errHandler struct {
	*slog.JSONHandler
}

func (h errHandler) Enabled(_ context.Context, l slog.Level) bool {
	if l >= slog.LevelError {
		return true
	}
	return false
}

Testing this with slogtest fails with got 6 results, want 15
But if I fork slogtest and replace every call of l.Info() (like this one https://github.com/golang/go/blob/go1.21.0/src/testing/slogtest/slogtest.go#L56) with l.Error() then it works.

I would love an option to tell slogtest.TestHandler() that the output method to use is Logger.Error

@komuw Your handler seems to be a specialization of this example.

I think wrapping handlers like those that don't actually affect the format don't need testing/slogtest. You can just write tests for the particular changes to behavior that they implement, and trust that the handler they wrap has passed slogtest.