8

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()
}
blackgreen
  • 34,072
  • 23
  • 111
  • 129
Freddie Sunarso
  • 113
  • 1
  • 6

2 Answers2

15

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)
        }
    }
}
Yury Petrov
  • 151
  • 1
  • 2
  • 2
    This is the proper answer. Use the observer for testing. – Howard Lince III Jun 25 '21 at 14:25
  • 1
    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 configs – Jose Miguel Ochoa Nov 17 '21 at 22:37
  • 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 }))` – ex8 Dec 27 '22 at 05:35
14

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")
    }
}
Peter
  • 29,454
  • 5
  • 48
  • 60
  • Thank you, this is very helpful. Is there a way to carry out the test if the `OutputPaths` is set to `[]string{"stdout"}` though? – Freddie Sunarso Oct 10 '18 at 23:17
  • 1
    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. – Peter Oct 11 '18 at 03:08
  • 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? – Freddie Sunarso Oct 11 '18 at 05:09
  • 1
    Either that or return the config instead of the finished logger and have the caller call Build(). – Peter Oct 11 '18 at 09:09