feat: Guided Tours E2E Tests

[camielvs]

Description

This PR is 100% AI generated.

End-to-end tests that replicate and verify the exact flow of every guided tour, so a UI change that breaks a tour is caught here (and points at the tour + step to fix) rather than shipping a broken tour.

Rather than four bespoke specs, this is a single data-driven driver that reads each tour's real JSON definition and walks it the way a user would:

• tests/e2e/tours/tourDriver.ts — runTour(page, tour) opens the tour, then for each step: asserts the step's spotlight anchor resolves in the DOM (the core regression signal), performs the gating interaction (or clicks Next for passive steps), and waits for the tour to advance (synchronised on the ?step=N URL the tour writes). It finishes on the completion step. A handler exists for every interaction type — drag-from-library, edge connection, task select, set-argument, undock/redock window, subgraph navigate/unpack, marquee multi-select, create-subgraph, and the full secrets flow.
• Specs — one thin spec per tour: navigating-editor, first-pipeline, subgraphs, using-secrets. Each loads the shipped tour JSON via loadTour(...), so the test tracks the real tour and new steps are covered automatically (modulo a brand-new interaction type needing a handler).
• eslint.config.js — teach playwright/expect-expect that runTour asserts internally.

Because the driver asserts each step's data-tour* anchor, removing or renaming an anchor a tour depends on fails the matching step by design.

The using-secrets spec exercises the no-backend path from #2405 / #2406: it fails the health ping and /api/secrets so the tour's in-memory mock backend serves the secret steps. The tour runs fully hands-on with normal gating, no /api/secrets calls fire, and the Submit Run confirm is asserted disabled (real run not wired in mock mode).

Related Issue and Pull requests

Closes https://github.com/Shopify/oasis-frontend/issues/644

Sits on top of the guided-tour stack (#2405 / #2406 and the framework/tour PRs below them).

Type of Change

• New feature

Checklist

• I have tested this does not break current pipelines / runs functionality
• I have tested the changes on staging

Test Instructions

• pnpm test:e2e tests/e2e/tours/ — all four tour specs pass (run in parallel against a local dev server).
• The using-secrets spec drives the no-backend path: it routes the health ping and /api/secrets to fail, so the tour's mockBackend activates and the in-memory mock serves the secret steps. It asserts no /api/secrets calls fire and that Submit Run stays disabled in mock mode.

Additional Comments

The centered tour popover overlaps a few dialog controls (Add Secret / submit confirm / the "Use Secret" lock button). The driver dispatches the click directly to those elements (clickThrough) so React's handler still fires — the only spot where it doesn't use a real mouse click.

[github-actions]

🎩 Preview

A preview build has been created at: 06-12-feat_guided_tours_e2e_tests/fb6be72

[camielvs]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• feat: Learning Hub - Milestone 2 #2416
• feat: Guided Tours Cleanup #2417
• feat: Guided Tours E2E Tests #2415 👈 (View in Graphite)
• feat: Guided Tours Completion Metrics #2412
• feat: Guided Tour - Secrets #2406
• feat: Guided Tours Framework (Secrets) #2405
• feat: Guided Tour - Subgraphs #2366
• feat: Guided Tours Framework (Subgraphs) #2365
• feat: Guided Tour - First Pipeline #2312
• feat: Guided Tours Framework (First Pipeline) #2347
• feat: Guided Tour - Navigating the Editor #2306 : 1 other dependent PR (#2307 )
• feat: Guided Tours Framework (Navigating the Editor) #2299
• feat: Guided Tours End Screen #2339
• feat: Guided Tours Ephemeral Pipelines #2334
• feat: Guided Tours Custom Navigation #2340
• feat: Guided Tours Foundation #2348
• feat: Learning Hub Guided Tours #2297
• feat: Learning Hub - Milestone 1 #2341
• feat: Learning Hub Tip of the Day #2292
• feat: Learning Hub Tip Browser #2291
• feat: Learning Hub Example Pipelines #2283
• feat: Learning Hub Documentation & FAQ #2282
• feat: Learning Hub Dashboard #2281
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

[camielvs]

🤖 This is an AI-generated code review comment.

performInteraction is the shared, tour-agnostic engine, but this set-argument branch hardcodes "tips" — a value meaningful only to the first-pipeline tour's dataset argument. A future tour that uses set-argument for a different field would silently get "tips" typed in and likely fail the step's gating check for a non-obvious reason.

Suggest carrying the value on the step (e.g. a targetArgumentValue field on TourStepDef, read here with a fallback) so the driver stays generic — or at minimum a comment noting this value is first-pipeline-specific. Low priority.

[camielvs]

🤖 This is an AI-generated code review comment.

This file is new here, so flagging: loadTour's comment (line 8) sells the design as drift-proof by reading the real shipped JSON — but the type here (TourStepDef / TourDef, with the interaction and target* fields) is still a hand-maintained copy of registry.ts's TourStep / TourDefinition, and JSON.parse(...) as TourDef (line 15) casts past any check. If the app renames a field, the driver type won't flag it (typescript-standards — prefer real types over as).

It's only Low because drift surfaces as a runtime test failure (an undefined selector/target) rather than silently-wrong behavior — so it's self-catching, just less precise than a compile error. Consider importing TourStep / TourDefinition from @/components/Learn/tours/registry and deriving the JSON-shaped subset, so a field rename becomes a type error right here.