Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a test for Development option #46

Merged
merged 3 commits into from
May 27, 2016
Merged

Add a test for Development option #46

merged 3 commits into from
May 27, 2016

Conversation

akshayjshah
Copy link
Contributor

@akshayjshah akshayjshah commented May 17, 2016

Fixes #55.

@prashantv
Copy link
Collaborator

Rather than this, I'd rather take the var stubbing approach to test this. That would allow us to test the Fatal calls in general, as well as DFatal

There is another option, which is kind of hacky, but could work, which is to:

  • Start a separate goroutine for the test
  • use a custom sink that will call runtime.Goexit (probably in the Flush call)
  • verify that the goroutine ends and check the contents

I think the first option is probably cleaner though

@akshayjshah
Copy link
Contributor Author

Sure, works for me.

prod := NewJSON().(*jsonLogger)
require.False(t, prod.development, "Expected default logger to be in production mode.")

dev := NewJSON(Development()).(*jsonLogger)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

where does Development() come from? testify?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's an option you can pass when creating a logger:
https://godoc.org/github.com/uber-common/zap#Development

We're using it to support the idea of DFatal which is an error log in production mode, but a fatal in test mode.

@coveralls
Copy link

coveralls commented May 27, 2016

Coverage Status

Coverage increased (+2.8%) to 99.142% when pulling a85b5fe on ajs-tests into 323dc68 on master.

@coveralls
Copy link

coveralls commented May 27, 2016

Coverage Status

Coverage increased (+2.8%) to 99.142% when pulling 9860061 on ajs-tests into 323dc68 on master.

@@ -35,6 +36,20 @@ func opts(opts ...Option) []Option {
return opts
}

type stubbedExit struct {
Status int
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

to distinguish vs being called with Exit(0) vs not being called, can we either use a separate bool to track whether it was called, or make Status a pointer.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, I completely overlooked that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

withJSONLogger(t, nil, func(jl *jsonLogger, output func() []string) {
jl.Log(Fatal, "foo")
assertMessage(t, "fatal", "foo", output()[0])
assert.Equal(t, 1, *stub.Status, "Expected to call os.Exit with status 1.")
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

optional nit: if exit isn't called, rather than failing with a nice error, it'll cause a panic. we could do

if assert.NotNil(t, stub.Status, "Expected a call to os.Exit") {
  assert.Equal(t, 1, *stub.Status, "os.Exit got unexpected exit code")
}

(i also try to not mention the specific value we expect in the message, since Equal will print the value it expected vs what it got already, and if we change it, it means less places to change / accidentally miss)

@prashantv
Copy link
Collaborator

lgtm with minor nit

@akshayjshah akshayjshah merged commit 4f8e68a into master May 27, 2016
@akshayjshah akshayjshah deleted the ajs-tests branch May 29, 2016 18:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

4 participants