I can speak only for myself, but I had to do precisely this for the first
time yesterday and it went pretty smooth.
Global logger declaration :
// Tests may instrument logger
var logger = stdlog.New(os.Stderr, "", 0)
Then, it the test suite :
buffer := new(bytes.Buffer)
logger = stdlog.New(buffer, "", 0)
doSomeStuff(....)
output := buffer.String()
for _, phrase := range []string{
"Foo foo foo",
"Bar bar bar",
} {
if !strings.Contains(output, phrase) {
t.Errorf("Expected %q", phrase)
}
}
Then I refactored a bit to restore the global logger after a test, now each
test method starts with :
buffer, hijack := logHijack()
defer hijack.Restore()
Cheers
Valentin
On Friday, July 8, 2016 at 6:33:37 AM UTC+2, 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.
>
> 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)
> 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)
> 3. What has been the litmus test for when the stdlib will provide an
> interface (like io.Writer)
>
--
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.
