Personally I’d prefer to start with a generic setup hook to avoid giving log any real special support. Then once it’s possible to manually hook any logging framework up we could consider making log special by automatically injecting a setup hook for it.
It does introduce more questions than just doing the special case though, how do you define the setup hooks, do we support per-crate and per-module (and all submodules) setup hooks for in-src tests, is there a way to specify a setup hook for all test files in the tests directory or are they all completely independent, what about doc-tests?
I’m not sure why a file would be needed here. It seems like just setting up a log handler that prints to stdout and using the existing stdout redirection would be enough. (Although, I seem to recall that there are issues with that redirection only actually affecting print! instead of all uses of stdout, but I think fixing that is preferable to introducing an alternative way to redirect test output).
The command line options also seem a bit extraneous, using env_logger for the handler lets you adjust the log levels via environment variables and having the same way to do so in tests and with the final binary seems good for introducing new developers to a crate that uses log extensively.
