-
Notifications
You must be signed in to change notification settings - Fork 9.4k
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
tests: add basic sentry tests #6308
Conversation
}); | ||
|
||
it('should skip expected errors', async () => { | ||
Sentry.init(configPayload); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what is an example of an expected error?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An audit that fails because its artifact errored. In that case we'd essentially be double reporting. The real error is the one that failed in the gatherer, so we just report that one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lighthouse/lighthouse-core/runner.js
Lines 269 to 274 in 3d5037a
// Create a friendlier display error and mark it as expected to avoid duplicates in Sentry | |
const error = new Error( | |
`Required ${artifactName} gatherer encountered an error: ${artifactError.message}`); | |
// @ts-ignore Non-standard property added to Error | |
error.expected = true; | |
throw error; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hoten it's pretty much only for controlling error reporting to Sentry. Basically it means this is an error, but we expect it often enough and it might be something the user needs to fix (or in the example @patrickhulce linked, we already reported it when it was a gatherer error, no reason to report it again).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
love this, just some questions about mocking style :)
*/ | ||
'use strict'; | ||
|
||
jest.mock('raven'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what's the unmocking behavior for this? The docs don't really make it clear. Does it rely on the tests being run in different processes so that other requires won't get a mock version?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
even in the same process jest
has a require sandbox that require is not real require and does auto-mocking of all kinds of things so there should be no need to unmock elsewhere (though even if it were mocked everywhere, I wouldn't be disappointed in the extra layer of assurance its not going to sentry :) )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah yeah, less worried about sentry (not) leaking in other tests than just how they work in general for future tests :)
|
||
originalSentry = {...Sentry}; | ||
originalMathRandom = Math.random; | ||
ravenConfigFn = jest.fn().mockReturnValue({install: jest.fn()}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can this just set these directly (raven.config = jest.fn().mockReturnValue({install: jest.fn()});
) and then do the expect()
checks below on the actual thing (expect(raven.config).toSomethingSomething
). For whatever reason that's easier for me to parse than checking expect(ravenConfigFn)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or from the docs it seems like you can also do raven.config.mockReturnValue({install: jest.fn()});
rather than the assignment. Does that work?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can this just set these directly
sure, no prob
it seems like you can also do raven.config.mockReturnValue({install: jest.fn()}); rather than the assignment. Does that work?
mostly :) the auto-mock only happens when the module is required in for the test, it's not reset for every it
. Rather than rely on the magic mocks, have reset methods, and do the configuration, it seemed clearer to do the explicit jest.fn
for the ones we're actually making assertions about. That make sense?
environmentData: {}, | ||
}; | ||
|
||
originalSentry = {...Sentry}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seems like sentry isn't modified anywhere?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
although, overriding Math.random is also kind of horrifying :) Maybe we should extract a shouldSample()
function on Sentry
and replace that in this test instead
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the Sentry object is mutated everytime you call init
, I'll add a comment about this.
shouldSample
works for me
}); | ||
|
||
it('should skip expected errors', async () => { | ||
Sentry.init(configPayload); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hoten it's pretty much only for controlling error reporting to Sentry. Basically it means this is an error, but we expect it often enough and it might be something the user needs to fix (or in the example @patrickhulce linked, we already reported it when it was a gatherer error, no reason to report it again).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! yay tests
@@ -37,6 +37,9 @@ const sentryDelegate = { | |||
getContext: noop, | |||
/** @type {(error: Error, options?: CaptureOptions) => Promise<void>} */ | |||
captureException: async () => {}, | |||
_shouldSample() { | |||
return SAMPLE_RATE >= Math.random(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
heh. check out sampleRate
on https://docs.sentry.io/clients/node/config/
I think they added it a while ago. I wonder why we never saw it.
Anyway, I think it's fine to use our solution for now. :)
Summary
adds a few basic tests for the sentry functionality
Related Issues/PRs
#6215