Maybe there's a reason it isn't like this already?
Anyway, the primary motivation was to have discovery failure messages appear on stderr, but this seems generally relevant.
make TestLogger write to stderr instead of stdout
Blanket dumping all console output to stderr is not a desired situation.
Ideally, we should be smarter about what we send where (and not just send everything to a single stream).
Well, right now we're dumping it all to stdout, which is wronger.
What should go to stdout and what should go to stderr? It seems like everything Testify writes through this logger --- progress messages, names of tests as they are run --- should be stderr. (--list-tests writes to stdout through a different system.)
I disagree that the current behavior is wronger. Testify is a program; its output is expected to go to stdout by default. Progress and status messages should always be on stdout - stderr is designed for just that, errors.
Specifically, discovery errors should go to stderr; possibly any other specific error messages from testify itself (not test failures).
StreamHandler defaults to stderr, even for log levels that are not errors.
Another example is dd: when you send it SIGUSR1 it prints a status message to stderr. curl (without -s) does the same for its progress bar.
IMO the purpose of stderr is not specifically to contain errors, but to be an out-of-band mechanism for reporting without polluting stdout, which might be piped. The testify output (except for --list-tests) is machine-unreadable, so you would never pipe it and it's a moot point. But I think the machine-unreadability is exactly why it would be better as stderr than stdout.
Anyway, I'm just arguing for the sake of arguing. Maybe I'll submit another patch later that sends internal errors only to stderr.