On Friday, 8 July 2016 07:33:37 UTC+3, zger...@pivotal.io wrote: > > Hey All, > > Originally asked on twitter but a more long-form medium is required to > answer this question. I've recently been working on adding logging to a > library and have been replacing what was once a custom logging interface > with just *log.Logger. > In so doing, I removed my ability to mock the logger (if I choose) and that > steered me towards not testing / test-driving any of my logging output. >
Why do you need to mock it? You can replace *log.Logger with one that writes to a *bytes.Buffer. Walking down this path led me to these specific questions: > > 1. Does any one REALLY test whether their app logs specific log lines > (when logging is not your the apps primary function) > Depends on whether the logs have value to the end-user or not. 2. Why isn't log.Logger just an interface instead of a struct (or why isn't > there a LogWriter interface that specifies a few of the log packages > multiple methods) > Packages should usually implement concrete types instead of interfaces. Interfaces should be declared by the user of the package. Interfaces add indirection and more code... when it's not necessary it's waste. Instead of understanding one thing you need to understand multiple things. 3. What has been the litmus test for when the stdlib will provide an > interface (like io.Writer) > I guess it's more of a standards based approach -- i.e. there's a standard way to write bytes to a file... however there is no standard way to log, there are tons of different approaches. -- 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. For more options, visit https://groups.google.com/d/optout.
