- Issue created by @spokje
- Status changed to Needs review
about 1 year ago 10:49am 12 November 2023 - 🇺🇸United States smustgrave
Use patch-packages all the time! Think this will need submaintainer or framework approval for the new packages.
- Status changed to Needs work
about 1 year ago 11:47am 16 November 2023 The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.
- Status changed to Needs review
about 1 year ago 12:38pm 21 November 2023 - First commit to issue fork.
- 🇬🇧United Kingdom longwave UK
Trying an alternative approach, viewing the source of
boxen
implies we might be able to use theCOLUMNS
environment variable to trick it into printing newlines. - Status changed to Needs work
about 1 year ago 1:57pm 28 November 2023 - First commit to issue fork.
- Status changed to Needs review
about 1 year ago 9:03am 29 November 2023 - 🇷🇺Russia kostyashupenko Omsk
Rebased, now patch from 5534 mr can be applied
- Status changed to Needs work
about 1 year ago 2:35pm 5 December 2023 - 🇺🇸United States smustgrave
Don't think needs submaintainer if not adding new package.
✔ Passed [ok]: true ok │ │ ✔ Passed [ok]: true ok │ │ ✔ Passed [equal]: Expected :tabbable to return 1 for element <input type="tel" tabindex="1" /> │ │ ✔ Passed [ok]: true ok │ │ ✔ Passed [ok]: true ok │ │ ✔ Passed [equal]: Expected :tabbable to return 0 for element <input type="tel" tabindex="-1" /> │ │ ✔ Passed [ok]: true ok │ │ ✔ Passed [ok]: true ok
Checked MR5534 and output isn't 2 columns anymore but the tests don't make sense. Just a bunch of "true ok"
- Status changed to Needs review
about 1 year ago 4:24pm 5 December 2023 - 🇬🇧United Kingdom longwave UK
That is because the tabbable test doesn't provide helpful assertion messages in two of the three assertions in the loop:
(result) => { browser.assert.ok(typeof result.value.actual === 'number'); browser.assert.ok(typeof result.value.expected === 'number'); browser.assert.equal( result.value.actual, result.value.expected, `Expected :tabbable to return ${result.value.expected} for element ${result.value.element}`, ); },
- Status changed to RTBC
about 1 year ago 4:46pm 5 December 2023 - 🇺🇸United States smustgrave
Ah okay, know we don't write a lot of nightwatch tests but may be worth opening a follow up to provide better mesages.
- Status changed to Needs work
about 1 year ago 9:22am 19 December 2023 - 🇳🇿New Zealand quietone
There are 2 MRs here, which one has been set to RTBC? I think it is the later one, which means the Issue Summary is out of date. Tagging for that as well.
- Status changed to Needs review
about 1 year ago 6:15am 4 January 2024 - 🇳🇱Netherlands spokje
*grmbl* Bloody newbies, always doing a drive-by MR *grmbl*
Anyway....
- Closed my MR
- Rebased longwave's MR
- Removed the unneeded/not working setting of COLUMNS as environment variable
- Updated ISSince there's technically a code change since the last RTBC (the removed line), putting this back to NR
- 🇳🇱Netherlands spokje
Hmmm, only just realized that we're now not able to see the approximately first third of the tests...
We can only scroll upto aroundoliveroStickyHeaderToggleTest
We seem to run out of the max amount of lines allowed on GitLab?
Is there a way to up that number for nightwatch log only?Personally, ATM I think I rather have (faux) two columns with all the results than correct aligned 2/3 of the testlog
- 🇬🇧United Kingdom longwave UK
Is it really helpful to show every passed assertion anyway? Should we set detailed_output to false? https://nightwatchjs.org/guide/configuration/customising-test-output.html
- Assigned to spokje
- Status changed to Needs work
about 1 year ago 12:20pm 4 January 2024 - 🇳🇱Netherlands spokje
Is it really helpful to show every passed assertion anyway?
Ah...
I was somehow under the impression that somebody somewhere explicitly wanted this very verbose output.Or we could set disable_colors to true and then the raw log should be more readable?
But but, I like the pretty colors....
Let's kill
detailed_output
and that should be more than enough to keep all the tests in view (and color ;) - Issue was unassigned.
- Status changed to Needs review
about 1 year ago 1:45pm 4 January 2024 - Status changed to RTBC
about 1 year ago 2:48pm 4 January 2024 - Status changed to Postponed
about 1 year ago 10:48am 8 January 2024 - 🇳🇱Netherlands spokje
Whilst we still have the very verbose output, let's use that to check if all deprecations are replaced in 📌 Replace deprecated functions in Nightwatch tests Fixed .
Postponing on that issue. - Status changed to Needs review
12 months ago 9:30am 15 January 2024 - 🇳🇱Netherlands spokje
📌 Replace deprecated functions in Nightwatch tests Fixed landed.
As a result, the lack of deprecation notices in the log now makes it short enough to be fully viewable in GitLab again.
Since I don't see a massive increase in Nightwatch tests/added assertions to existing test, I removed thedetailed_output: false
.Back to NR.
- Status changed to RTBC
12 months ago 3:19pm 17 January 2024 - 🇪🇸Spain fjgarlin
The change seems simple enough and the output is defo better (see https://git.drupalcode.org/issue/drupal-3401047/-/jobs/633328).
I don't know how much more we can control it, so I'm setting this RTBC. - 🇫🇷France andypost
Blocker reverted 📌 Replace deprecated functions in Nightwatch tests Fixed
- Status changed to Fixed
12 months ago 12:30pm 23 January 2024 Automatically closed - issue fixed for 2 weeks with no activity.