/area test-and-release
This came up during discussion with Mustafa about zap. Given all the benefits Mustafa listed for zap, it's gonna be useful for test failure troubleshooting.
"zap is a structured logging library. If you take advantage of structured logs, then you should use zap.
For example, in tests, I can see it being used the following way:
You create a zap logger with the context of a test (for example: logger.Named(testName)). From this point on, any test that is using that logger will have a key/value pair that says "logger": testName.
When looking within the logs, you can easily filter logs for a failed test by searching "logger": "failed test name"
in addition, you can add first class fields, such as "TestResult": "Failed/succeeded". That way, rather than searching for a term "error" and getting a lot of false positives, you can find exactly what test is failing
You also get the benefit of seeing a full stack trace when you say logger.Error
My only recommendation would be to set up the zap logger to use "Console encoder" to make it easier to read from the web"
In addition, you can populate extra context about the test's context (some useful debugging informaton for example, like certain environment variables or configuration options that you use different from lets say a default installation)
"
/area test-and-release
This came up during discussion with Mustafa about zap. Given all the benefits Mustafa listed for zap, it's gonna be useful for test failure troubleshooting.
"zap is a structured logging library. If you take advantage of structured logs, then you should use zap.
For example, in tests, I can see it being used the following way:
You create a zap logger with the context of a test (for example: logger.Named(testName)). From this point on, any test that is using that logger will have a key/value pair that says "logger": testName.
When looking within the logs, you can easily filter logs for a failed test by searching "logger": "failed test name"
in addition, you can add first class fields, such as "TestResult": "Failed/succeeded". That way, rather than searching for a term "error" and getting a lot of false positives, you can find exactly what test is failing
You also get the benefit of seeing a full stack trace when you say logger.Error
My only recommendation would be to set up the zap logger to use "Console encoder" to make it easier to read from the web"
In addition, you can populate extra context about the test's context (some useful debugging informaton for example, like certain environment variables or configuration options that you use different from lets say a default installation)
"