CLI: Remove confusing expected: undefined
from TAP for non-assert fail
#1794
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.
pushFailure
This was setting
actual: null
and, left expected unset/undefined. In HtmlReporter this idom was recognised to mean "don't show values", based on hasOwn forexpected
. This worked because QUnit.log() passes the internal assert result object as-is.In TAP output, this was not skipped because Test.js#logAssertion copies the object for the testEnd.errors array, and in doing so forges an
expected
property to exist no matter what, thus with an implied value of undefined. The hasOwn checks in TapReporter thus always evaluate to true.This meant TAP output for pushFailure() calls not only showed redundant actual/expected entries, but actively created confusion by setting them to different values, drawing attention to a supposed difference that has no meaning
Fix by changing pushFailure to omit both actual and expected, and change the condition in both reporters to skip rendering of values based on both being strictly equal to
undefined
, instead of based onhasOwn('expected')
.Before:
After:
onUncaughtException /
QUnit.on('error')
For uncaught errors, we already omitted both actual and undefined, the HtmlReporter thus already skipped them (for the reason above), but in TAP output they showed, for the same reason as above as:
Which, while not as actively confusing, is at least redundant. This is naturally fixed by the same change, which now omits this.
Before:
After: