Admin UI end-to-end test waits out the job refresh interval in real time

Open Beginner friendly
#2,693 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
88/100
Issue type
Refactor
Clarity
Clearly specified
Activity status
Quiet
Tech stack
playwright, typescript
Domain
testing-qa

Research direction

Start in ui/e2e/auth.spec.ts:211 and read the fake-clock convention in ui/CONTRIBUTING.md. Compare the positive control in ui/e2e/jobs.spec.ts, then run the session-expiry test to verify the failing poll is driven without real-time waiting. Done means the existing assertion remains unchanged and the test completes well under a second.

Written by the indexing model from the issue text.

Description

testing ui

ui/e2e/auth.spec.ts:211, "shows the failure in the session expiry dialog and keeps it open", takes around 13 seconds and is now the slowest test in the Admin UI end-to-end suite by a wide margin - the next slowest is 9.7s, and most tests are under 2s.

The cost is structural rather than incidental. The test arranges for the first job list request to succeed and every later one to return 401, then waits for the session expiry dialog that the failed poll raises. Raising that dialog requires a second poll, so the test cannot proceed until the idle refresh interval of ten seconds has elapsed in real time. The timeout: 15000 on the dialog assertion exists to accommodate that.

This escaped #2690, which removed the two page.waitForTimeout() calls in the suite and added a lint rule to keep them out. Here the wait is expressed as a genuine expect(...).toBeVisible() on a real condition, so neither the scope of that change nor the new playwright/no-wait-for-timeout rule catches it. It is a de-facto sleep wearing the clothes of a proper wait.

The same treatment that fixed the other two should apply: install Playwright's clock before authenticating, and advance it past the refresh interval to drive the failing poll, rather than waiting for it. That would bring the test into line with the convention now documented in ui/CONTRIBUTING.md, and should reduce it to well under a second. The positive control added to ui/e2e/jobs.spec.ts in #2690 already guards the property that advancing the fake clock genuinely drives the refetch, so no new control is needed.

No assertion needs to change, and no application code is involved.

Dominant language
Java
Stars
134
Forks
24
Avg merge
2d 17h
Merged PRs (30d)
10

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from aehrc/pathling

All issues in aehrc/pathling

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.