-
Notifications
You must be signed in to change notification settings - Fork 1.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
Improve test result accessibility #3082
Improve test result accessibility #3082
Conversation
Color covers figure and label, and indicates passed-as-expected vs. not (expected/unexpected fail or unexpected pass). Fixes avajs#2919
This produces lots of failures like the following; how do I update the [TAP] test expectations in bulk?
|
This _seems_ to work, but the resulting interaction between CommonJS and ESM feels a bit Zalgo-y. It may be better for modules to keep setting global options and chalk options in parallel while the former remains CommonJS, but I wanted to see what simplification would look like.
lib/worker/options.cjs
Outdated
if (setChalk) { | ||
setChalk(options.chalkOptions); | ||
} else { | ||
chalk.then(chalk => chalk.set(options.chalkOptions)); | ||
} |
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.
This is from 1b64bff, an independent experiment that can be reverted if deemed unsuccessful.
This seems to work, but the resulting interaction between CommonJS and ESM
feels a bit Zalgo-y. It may be better for modules to keep setting global
options and chalk options in parallel while the former remains CommonJS,
but I wanted to see what simplification would look like.
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.
Is this needed for this PR? Can we discuss it in a separate PR? It's all a little complicated I know, do we need to change it? What do you think the benefits are?
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.
I'd prefer to keep it, because otherwise the new tests don't correspond with reality (because worker output does not consistently respect color settings) and will undergo a fair amount of churn. But if you feel strongly that it should be separated, I can do that.
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.
I had a go at removing it, and other than test-tap/assert.js
requiring an extra stripAnsi()
there's no impact. I think I prefer the "set once" approach rather than having code react to changes.
lib/worker/options.cjs
Outdated
if (setChalk) { | ||
setChalk(options.chalkOptions); | ||
} else { | ||
chalk.then(chalk => chalk.set(options.chalkOptions)); | ||
} |
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.
Is this needed for this PR? Can we discuss it in a separate PR? It's all a little complicated I know, do we need to change it? What do you think the benefits are?
@sindresorhus what do you think? |
Thank you @gibson042, very exciting! Note that we're seeing similar CI failures on the |
I agree with almost everything. However, I'm not a big fan of the |
@sindresorhus Without "PASS" and "FAIL", vision-impaired consumers are left to infer semantics from information like "check mark" and "multiplication symbol" (the latter improved a bit after sindresorhus/figures#92 ). I'd prefer to keep the verbosity in support of accessibility and output consistency, but if you still disagree then let me know and I'll remove them. |
@gibson042 I should have some time this week to help get this over the line. |
@sindresorhus how strongly do you feel about this? I do like the consistency. |
I don't feel strongly about it. |
Most assertion will be pass or fail, so there wouldn't be much inconsistency in practice. And it may even have been beneficial to make the uncommon cases more obvious. The result now is also more noisy. |
Use lowercase, since AVA doesn't output anything in all caps. Wrap in square brackets to differentiate from the test title. Remove prefix for passed tests. We assume that most tests pass most of the time.
To better differentiate from the test title.
Project name aside, we don't really use all caps. I've pushed a commit to use lowercase and put it in square brackets. Most of the time, most tests pass. So I've removed the prefix for passed tests. I also noticed that the assertion message was only differentiated from the test title by color, so I've made that italic. |
Fixes #1558
Fixes #2919