fix: #3621374 Move the Drimage assertions to the varbase-e2e step pack

Issue: #3621374 Remove the local "the image ... should be loaded" step, now ambiguous with @vardot/varbase-e2e 2.0.4

Why

@vardot/varbase-e2e 2.0.4 ships a Drimage Improved step pack — ported out of this suite so every site using the module gets the steps from the package — and its single-image step matched the sentence we defined locally, so Cucumber failed the run with Multiple step definitions match: 3 of the 17 scenarios.

Then the image "[data-drimage_improved] picture img" should be loaded within 2 seconds
  • Ours: tests/step-definitions/drimage.steps.js:21
  • The library's: drupal-drimage-improved.steps.js:194

What changed

  • Deleted tests/step-definitions/drimage.steps.js; the pack supersedes it.
  • Moved the assertions in tests/features/drimage/*.feature to the pack's wording: the drimage images should be rendered / should be loaded / should offer webp / should have a noscript fallback.
  • Kept one raw selector — the @webp-off negative check, since the pack has no negative webp step.
  • Dependency ^2 → ^2.0.4; the pack does not exist before it.
  • README points at the pack instead of documenting a local step, and the cucumber.js comment is reworded.

Why the feature files had to change too: in the pack the quoted text is the image's alt text, not a CSS selector — it already knows the formatter markup and the /styles/drimage_improved_ derivative path. Left as they were, those lines would have failed rather than been ambiguous, looking for an image whose alt text is [data-drimage_improved] picture img. The pack also covers more than we did. Its docs.

Verified

npx cucumber-js --dry-run --format progress: 17 scenarios, 244 steps, nothing ambiguous, nothing undefined (before: 3 ambiguous).

The pipeline on this MR is fully green, including all four functional-acceptance browser jobs (base, focal_point, image_widget_crop, webp_off), so the rewritten scenarios pass against real built sites.

Unrelated and pre-existing: @cucumber/pretty-formatter does not load against the installed Cucumber after a plain npm install — it fails the same way at the untouched 1.0.x tip — hence --format progress.

AI-Generated: Yes

Checkpoints:

  • File an issue
  • Addition/Change/Update/Fix
  • Testing to ensure no regression
  • Automated unit testing coverage
  • Automated functional testing coverage
  • UX/UI designer responsibilities
  • Readability
  • Accessibility
  • Performance
  • Security
  • Developer Documentation
  • User Guide Documentation
  • Reviewed by human
  • Code review by maintainers
  • Full testing and approval
  • Credit contributors
  • Review with the product owner
  • Release notes snippet
  • Release
Edited by Rajab Natshah

Merge request reports

Loading
Loading