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

CLI: Remove confusing expected: undefined from TAP for non-assert fail #1794

Merged
merged 1 commit into from
Aug 7, 2024

Conversation

Krinkle
Copy link
Member

@Krinkle Krinkle commented Aug 7, 2024

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 for expected. 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

actual: null
expected: undefined

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 on hasOwn('expected').

Before:

TAP version 13
not ok 1 example
  ---
  message: Expected 2 assertions, but 1 were run
  severity: failed
  actual  : null
  expected: undefined
  stack: |
        at /test/example.test.js:1:7

After:

TAP version 13
not ok 1 example
  ---
  message: Expected 2 assertions, but 1 were run
  severity: failed
  stack: |
        at /test/example.test.js:1:7

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:

actual: undefined
expected: undefined

Which, while not as actively confusing, is at least redundant. This is naturally fixed by the same change, which now omits this.

Before:

TAP version 13
Bail out! Error: boo example
  ---
  message: Error: boo example
  severity: failed
  actual  : undefined
  expected: undefined
  stack: |
        at /test.js:3:7
  ...

After:

TAP version 13
Bail out! Error: boo example
  ---
  message: Error: boo example
  severity: failed
  stack: |
        at /test.js:3:7
  ...

== 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 for `expected`. 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

> actual: null
> expected: undefined

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
on `hasOwn('expected')`.

== 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:

> actual: undefined
> expected: undefined

Which, while not as actively confusing, is at least redundant.
This is naturally fixed by the same change, which now omits this.
@Krinkle
Copy link
Member Author

Krinkle commented Aug 7, 2024

Cross-ref #1789 (thematically related: polishing CLI/TAP output)

@Krinkle Krinkle added this to the 3.0 release milestone Aug 7, 2024
@Krinkle Krinkle merged commit 9a1fc05 into main Aug 7, 2024
21 checks passed
@Krinkle Krinkle deleted the cli-trace-cleaner branch August 7, 2024 22:57
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.

1 participant