fix: Include impression data status when not enabled #122
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What
This PR fixes a bug in how impression data is reported when
impressionDataAll
is set to true: When a feature hasimpressionData: false
butimpressionDataAll
is set to true, it will now reportimpressionData: false
instead ofimpressionData: undefined
.Why
This is a bug because we should report the state of impression data for a feature when we can. In the original feature PR discussion, it was agreed to make
impressionData
aboolean | undefined
where it would be reported as a boolean if we knew the state andundefined
otherwise.It seems to have been an oversight in the tests.
Clarifications
What's with the try/catch blocks in the tests?
It's explained more thoroughly in the callback section of Jest's testing asynchronous code, but in short:
If you don't have the try/catch and one of the expectations fail, then the done callback is never called (because the function short circuits). While this does mean that the test fails (this is good), it fails with a message saying that it exceeded the set timeout and not because it failed an expectation (this is bad).
To instead have the correct error message reported, you must catch the error and pass it to the done callback. This will make the test fail and report the correct error message.
Now regarding using
finally
, I did consider that but ended up not doing it for the following reason:Calling the done callback requires the error for it to fail. This can't be done in a finally block because you don't have access to the error. In theory, you could probably declare an error variable that you set to undefined and then assign in the catch block, but that doesn't feel any cleaner to me.