Skip to content

test(e2e): guard the flow controls, the one layer that could have caught this - #2353

Merged
rubenvdlinde merged 2 commits into
developmentfrom
test/flow-controls-e2e
Aug 5, 2026
Merged

test(e2e): guard the flow controls, the one layer that could have caught this#2353
rubenvdlinde merged 2 commits into
developmentfrom
test/flow-controls-e2e

Conversation

@rubenvdlinde

Copy link
Copy Markdown
Contributor

Why

The flow authoring surface shipped unreachable — no save, run, enable, add a step or run history (fixed in #2351). Every layer was green while it was broken: the components existed, the routes existed, unit tests passed, the manifest validated, and the manifest key meant to mount the panel (sidebarComponent) was silently outranked by the app's own #sidebar slot.

Nothing short of opening the page and looking for the controls could have caught that. So that is what this spec does.

Asserts

  1. the sidebar renders, with its palette and actions
  2. the palette is non-empty — an empty one renders the same container, so the count is the real check that /api/flow/node-catalog loaded
  3. a step added from the palette reaches the canvas
  4. Save persists — proven by the route advancing off new to the server's uuid
  5. Run now creates a run for that flow

What it deliberately does not assert

That the run completes. Execution is picked up by FlowRunWorker on cron, which does not run in CI; waiting for it would make the spec depend on a background job and go flaky. That the run is created and attributed to the flow is the part the UI is answerable for.

Verified both ways

A passing assertion is evidence about the assertion until it has been shown to fail.

bundle result
with the fix passes
fix reverted, bundle rebuilt fails on the sidebar assertion, with the message written for exactly that case

Hermetic

Builds its own flow through the UI and deletes it in a finally, so a mid-test failure still cleans up — the CI floor's contract.

…ght this

The flow authoring surface shipped unreachable — no save, run, enable, add a
step or run history — and every layer was green while it was broken. The
components existed, the routes existed, unit tests passed, the manifest
validated, and the manifest key that was supposed to mount the panel
(`sidebarComponent`) was silently outranked by the app's own #sidebar slot.

Nothing short of opening the page and looking for the controls could have
found that, so that is what this does.

Asserts, in order: the sidebar renders with its palette and actions; the
palette is non-empty (an empty one renders the same container, so the count
matters); a step added from the palette reaches the canvas; Save persists,
proven by the route advancing off `new` to the server's uuid; and Run now
creates a run for that flow.

It deliberately stops short of asserting the run COMPLETES. Execution is
picked up by FlowRunWorker on cron, which does not run in CI — waiting for it
would make the spec depend on a background job. That the run is created and
attributed to the flow is the part the UI is answerable for.

Hermetic per the CI floor's contract: it builds its own flow through the UI
and deletes it in a `finally`, so a mid-test failure still cleans up.

Verified both ways against a live instance, because a passing assertion is
evidence about the assertion until it has been shown to fail: with the fix it
passes, and with the fix reverted and the bundle rebuilt it fails on the
sidebar assertion with the message written for exactly that case.
@github-actions

github-actions Bot commented Aug 5, 2026

Copy link
Copy Markdown
Contributor

Quality Report — ConductionNL/openregister @ 54fed5a

Check PHP Vue Security License Tests
lint
phpcs
phpmd
psalm
phpstan
phpmetrics
eslint
stylelint
build
check-specs
test-l10n
composer ✅ 173/173
npm ✅ 713/713
PHPUnit
Newman
Playwright
Hydra gates

Quality workflow — 2026-08-05 20:17 UTC

Download the full PDF report from the workflow artifacts.

CI failed the new spec on the click, not on the app. Playwright resolved the
"New flow" button, reported it visible, enabled and stable, scrolled it into
view — and then the click action itself timed out, twice, burning the whole
45s budget with the locator perfectly matched.

That is the Nextcloud themed-button behaviour `tests/e2e/global-setup.ts`
already documents against the login button: "on NC's themed login the styled
submit button can swallow the click". The class on the failing control says
the same thing out loud — `button-vue--legacy34`.

Every click in the spec now goes through one helper that asserts visibility
and then dispatches the event, which drives the Vue @click handler that is
the actual behaviour under test. It costs Playwright's actionability checks,
so the explicit `toBeVisible()` assertions stay: those are what catch a
control that is missing or covered, which is the regression this spec exists
for.

It passed locally three times before CI disagreed — worth recording, because
the local pass was the less trustworthy of the two results.
@github-actions

github-actions Bot commented Aug 5, 2026

Copy link
Copy Markdown
Contributor

Quality Report — ConductionNL/openregister @ ae266ef

Check PHP Vue Security License Tests
lint
phpcs
phpmd
psalm
phpstan
phpmetrics
eslint
stylelint
build
check-specs
test-l10n
composer ✅ 173/173
npm ✅ 713/713
PHPUnit
Newman
Playwright
Hydra gates

Quality workflow — 2026-08-05 21:45 UTC

Download the full PDF report from the workflow artifacts.

@rubenvdlinde
rubenvdlinde merged commit 25d4dff into development Aug 5, 2026
30 checks passed
@rubenvdlinde
rubenvdlinde deleted the test/flow-controls-e2e branch August 5, 2026 21:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant