How to test logging of a zap Logger built from custom Config?
Asked Answered
B

2

10

I have a Zap logger that is generated from a custom Config (i.e. config.Build()). I would like to test the logger by calling, for example, logger.Info() in the test method and assert the result to see if it is according to the config set. How can I achieve this?

Code example:

func GetLogger() *zap.Logger{
 config := &zap.Config{
  Encoding: "json",
  Level: zap.NewAtomicLevelAt(zapcore.InfoLevel),
  OutputPaths: []string{"stdout"},
  ErrorOutputPaths: []string{"stdout"},
  EncoderConfig: zapcore.EncoderConfig{
   MessageKey: "@m",
   LevelKey:    "@l",
   EncodeLevel: zapcore.CapitalLevelEncoder,
   TimeKey:    "@t",
   EncodeTime: zapcore.EpochMillisTimeEncoder,
   CallerKey:     "@c",
   EncodeCaller:  zapcore.ShortCallerEncoder,
   StacktraceKey: "@x",
  },
 }
 return config.Build()
}
Bog answered 10/10, 2018 at 7:6 Comment(1)
Both answers are also applicable to any logger, not just those built from custom configsCarlocarload
W
13

Zap has a concept of sinks, destinations for log messages. For testing, implement a sink that simply remembers messages (for instance in a bytes.Buffer):

package main

import (
    "bytes"
    "net/url"
    "strings"
    "testing"
    "time"

    "go.uber.org/zap"
)

// MemorySink implements zap.Sink by writing all messages to a buffer.
type MemorySink struct {
    *bytes.Buffer
}

// Implement Close and Sync as no-ops to satisfy the interface. The Write 
// method is provided by the embedded buffer.

func (s *MemorySink) Close() error { return nil }
func (s *MemorySink) Sync() error  { return nil }


func TestLogger(t *testing.T) {
    // Create a sink instance, and register it with zap for the "memory" 
    // protocol.
    sink := &MemorySink{new(bytes.Buffer)}
    zap.RegisterSink("memory", func(*url.URL) (zap.Sink, error) {
        return sink, nil
    })

    conf := zap.NewProductionConfig() // TODO: replace with real config

    // Redirect all messages to the MemorySink.    
    conf.OutputPaths = []string{"memory://"}

    l, err := conf.Build()
    if err != nil {
        t.Fatal(err)
    }

    l.Info("failed to fetch URL",
        zap.String("url", "http://example.com"),
        zap.Int("attempt", 3),
        zap.Duration("backoff", time.Second),
    )

    // Assert sink contents

    output := sink.String()
    t.Logf("output = %s", output)

    if !strings.Contains(output, `"url":"http://example.com"`) {
        t.Error("output missing: url=http://example.com")
    }
}
Waterbuck answered 10/10, 2018 at 10:18 Comment(4)
Thank you, this is very helpful. Is there a way to carry out the test if the OutputPaths is set to []string{"stdout"} though?Bog
Generally, yes. os.Stdout is just a variable that can be reassigned. But I strongly recommend not doing that, because of the side effects. I'm not sure that you will see the test report, for instance. The Output fields should not influence how the logger works, so I'm not sure why you want to use "stdout" in the test.Waterbuck
Gotcha, I have just added an example in the question to clarify what I mean, basically I would like to test the logger returned by the function GetLogger(). But from your response, it seems that it would be better if I just pass the outputPaths as a function parameter, so I can have a different value for the unit test?Bog
Either that or return the config instead of the finished logger and have the caller call Build().Waterbuck
S
17

zap has a special zaptest/observer module made for unit testing:

package test

import (
    "testing"

    "go.uber.org/zap"
    "go.uber.org/zap/zaptest/observer"
)

func setupLogsCapture() (*zap.Logger, *observer.ObservedLogs) {
    core, logs := observer.New(zap.InfoLevel)
    return zap.New(core), logs
}

func Test(t *testing.T) {
    logger, logs := setupLogsCapture()
    
    logger.Warn("This is the warning")
    
    if logs.Len() != 1 {
        t.Errorf("No logs")
    } else {
        entry := logs.All()[0]
        if entry.Level != zap.WarnLevel || entry.Message != "This is the warning" {
            t.Errorf("Invalid log entry %v", entry)
        }
    }
}
Stradivarius answered 22/6, 2020 at 21:42 Comment(3)
This is the proper answer. Use the observer for testing.Bargainbasement
The method observer.New returns a new zap core. What if I have an existing core and want to observe that one? It seems like such method abstracts away the ability to create custom configsSpiegel
I had a similar issue with a custom config logger. I ended up replacing the zapcore with the one observer returns. l := logger.log.Sugar().WithOptions(zap.WrapCore(func(c zapcore.Core) zapcore.Core { return core }))Lunseth
W
13

Zap has a concept of sinks, destinations for log messages. For testing, implement a sink that simply remembers messages (for instance in a bytes.Buffer):

package main

import (
    "bytes"
    "net/url"
    "strings"
    "testing"
    "time"

    "go.uber.org/zap"
)

// MemorySink implements zap.Sink by writing all messages to a buffer.
type MemorySink struct {
    *bytes.Buffer
}

// Implement Close and Sync as no-ops to satisfy the interface. The Write 
// method is provided by the embedded buffer.

func (s *MemorySink) Close() error { return nil }
func (s *MemorySink) Sync() error  { return nil }


func TestLogger(t *testing.T) {
    // Create a sink instance, and register it with zap for the "memory" 
    // protocol.
    sink := &MemorySink{new(bytes.Buffer)}
    zap.RegisterSink("memory", func(*url.URL) (zap.Sink, error) {
        return sink, nil
    })

    conf := zap.NewProductionConfig() // TODO: replace with real config

    // Redirect all messages to the MemorySink.    
    conf.OutputPaths = []string{"memory://"}

    l, err := conf.Build()
    if err != nil {
        t.Fatal(err)
    }

    l.Info("failed to fetch URL",
        zap.String("url", "http://example.com"),
        zap.Int("attempt", 3),
        zap.Duration("backoff", time.Second),
    )

    // Assert sink contents

    output := sink.String()
    t.Logf("output = %s", output)

    if !strings.Contains(output, `"url":"http://example.com"`) {
        t.Error("output missing: url=http://example.com")
    }
}
Waterbuck answered 10/10, 2018 at 10:18 Comment(4)
Thank you, this is very helpful. Is there a way to carry out the test if the OutputPaths is set to []string{"stdout"} though?Bog
Generally, yes. os.Stdout is just a variable that can be reassigned. But I strongly recommend not doing that, because of the side effects. I'm not sure that you will see the test report, for instance. The Output fields should not influence how the logger works, so I'm not sure why you want to use "stdout" in the test.Waterbuck
Gotcha, I have just added an example in the question to clarify what I mean, basically I would like to test the logger returned by the function GetLogger(). But from your response, it seems that it would be better if I just pass the outputPaths as a function parameter, so I can have a different value for the unit test?Bog
Either that or return the config instead of the finished logger and have the caller call Build().Waterbuck

© 2022 - 2025 — McMap. All rights reserved.