[pull] main from qunitjs:main #1
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
Add a bit more detail.
== 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.
When projects use the recommended structure for the HTML test suite, in which qunit.js is loaded at the end of the `<body>` we now render the UI immediately instead of waiting for all source code and test suites to load first, which can take a while in large projects. Closes #1793.
Follows-up 68d30ec, which added docs/browser.md.
Follows-up d8c2a3a. This felt like a hacky compromise and doesn't quite feel right either way. Let's leave flowing as before for now. What I did add is to expose the version and user agent as data attributes, to empower other themes and plugins to play with this and perhaps come up with a better design.
Follows-up 05e15ba, which made this into a factory function, but that has the downside of making the QUnit object not defined in one object literal, which makes a few other things reasier to reason about. In a way, it's more honest to say that start is the product of a factory function, but I'd prefer to maintain the simplicity of an uncoupled literal declaration the entire API, in particular in prep for native ESM export (ref #1551). I'll accept in return the internal responsiblity to not call start() "incorrectly" (i.e. before it is ready). This responsibility does not leak into, complicate, break, or otherwise change the public API, and is mitigated by a runtime detection, for the benefit of future contributors and maintainers to QUnit.
Avoid dumping the entire QUnit object.
Extracted from #1798 to minimize the diff.
Node.js fetch() is non-experimental as of Node.js 18.0.0. Test Plan: * Run `node build/review-package.js 3.0.0-alpha.2`. * This should download _temp/package.json and offer it for diffing. * This should then download _temp/qunit.js and offer it for diffing.
Fixes #1733. Co-authored-by: Vivien Tintillier <[email protected]>
Don't apply colors to the "ok 1" and "not ok 1" prefix. This has the benefit of making the test names easier to visually extract for developers. It also increases compatibility with the popular `tap-parser` package which doesn't parse TAP lines correctly otherwise, since blocks like "not ok" must start on a new line, and with the color code in front, they are technically either a continuation of the previous block, or an ignored "Anything" line between two blocks. https://github.com/tapjs/tapjs/tree/ccfea67fec/src/parser https://testanything.org/tap-version-13-specification.html Closes #1801.
Closes #1750.
> [BROWSERSTACK_DEVICE_DEPRECATION_WARNING] This is to inform you that we have > decided to deprecate iPhone 8-12, effective 5 November 2024. For more details, > please check our device deprecation policy FAQ > https://www.browserstack.com/question/790 > https://www.browserstack.com/support/faq/automate/basics-automate/device-deprecation-policy > . If you are still using this device, we strongly recommend you update your > test script or risk your tests failing. For the current list of supported > devices on BrowserStack, please check here > https://www.browserstack.com/list-of-browsers-and-platforms/automate
Follows-up 06424ba. This ensures reproducible builds for e.g. minor changes in Rollup or Babel. Also remove the file trigger from `.github/workflows/reproducible.yaml` which otherwise triggers on release commits and release branches, because it seems GitHub interprets release branches/tags as creating all files, and thus matching all files. Exclude 3.0.0-alpha.3 because it still committed package-lock.json, and contained older versions than the working copy I released it with.
* Improve and simplify test case naming. * Inline the test case "expected" output for improved comprehension of the purpose of the test, and to make it easier to edit in the future. This was the last remnant of the expected/ directory that we used to use for cli-main.js as well. (The latter has mostly been moved to inline cases as well, plus many using the `.tap.txt` files for simple cases where what's being tested is all in the fixture file, and not in cli-main.js itself.) * Use QUnit.test.each() to make the difference between the first two tests easier to spot. This isn't code de-duplication per-se, since I don't mind that much, but it's to clarify what's difference since they looked nearly the same.
The `paths` filter isn't just about commits that add or modify files, GitHub seemingly also triggers this for any new tags and new branches that inherit from existing commits/branches where these files already exist, even if the new branch/tag does not add or modify these files at all. This seems like a bug, but is sufficiently annoying (especially on older 2.x-related branches) that it's better to turn off in favour of manual workflow_dispatch for the rare case where I want to test this before a given commit is merged to main.
We need the function internally either way, for its internal features, such as `undefOnly`. Too widely used in the ecosystem. Not worth the effort for devs to have change their code as part of upgrading QUnit, and possibly stagnating on an older QUnit version over (if not in their own code, but e.g. a plug-in). See also: * 82c4790: Remove `extend`. * 335b040: Document removal of `extend`. * eaa0dbe: Restore `assert.push` without deprecation.
|
Important Review skippedBot user detected. To trigger a single review, invoke the You can disable this status message by setting the 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
* Fix huge color contrast issue with the dark red background behind similarly dark colors, especially in `.counts`. * Remove white padding between test item edge and assert list assertion green/red shading. Instead, add some border-spacing to the assert item table. * Adjust various colors slightly to comply with WCAG guidelines. https://developer.mozilla.org/en-US/docs/Web/Accessibility/Understanding_WCAG/Perceivable/Color_contrast * Fix broken `.qunit-test.pass .test-expected { color: #999; }` override which was only applicable to passing "todo" tests as no other passing tests have failing assertions under them. This was meant to mute the colors of these failures to avoid distraction. However the CSS cascade has changed over time such that these styles no longer applied. This is likely masked by the fact that passing tests (including passing todos) are collapsed by default, so there's very little attention to these anyway. Restore these overrides, and extend them to the "diff" and "source" lines as well. Easy way to identify color usage: ``` $ git grep '#[0-9A-F][0-9A-F]*' src/core/qunit.css | sed 's/^.*\(#[0-9A-F]*\).*/\1/' | sort | uniq -c ``` Ref #1774. Closes #1803.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )