agentleFS
suitenumeriquesuitenumerique/docs/.agents/skills/docs-e2e-test/SKILL.md

docs-e2e-test

Skill17k starsChanged 7 days agoMITView on GitHub

Work on end-to-end tests for La Suite Docs using Playwright. Use this skill when creating, modifying, debugging, or reviewing E2E tests, especially under src/frontend/apps/e2e/__tests__/app-impress. Prefer focused Chromium tests, reuse existing utilities and existing tests before creating new code, and avoid running the full E2E suite unless explicitly necessary.

  • Reads credentials

Adopted by

Steady: 0 new projects took it in the last 4 weeks, none the 4 weeks before.thin data

Week of Sep 13: 0 new projectsWeek of Sep 20: 0 new projectsWeek of Sep 27: 0 new projectsWeek of Oct 4: 0 new projectsWeek of Oct 11: 0 new projectsWeek of Oct 18: 0 new projectsWeek of Oct 25: 0 new projectsWeek of Nov 1: 0 new projects
Sep 2026Oct 2026Nov 2026
New projects taking a version of this file each week, over the 8 weeks our latest run read: only 0 in all, so this is a hint, not a trend.

Who's talking about suitenumerique/docs

The biggest 5 of 110 mentions linking to the repository that our crawl found. Each line is their own headline.

See all 110

Talked about on GitHub, Bluesky, YouTube and Hacker News (110 times).

On GitHub · 50

45 more on GitHub

On Bluesky · 47

42 more on Bluesky

On YouTube · 11

6 more on YouTube

On Hacker News · 2

The file

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 2 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Run the narrowest scope, from src/frontend/apps/e2e:

    line 18
  2. Very specific:

    If tests fail with HTTP 429, the throttling of the dev backend is too low: the CI raises it by appending env.d/development/common.e2e to …

    line 31
  3. Very specific:

    Never run Firefox or WebKit (--project=firefox|webkit, yarn test:ui::firefox|webkit) unless asked.

    line 35
  4. Very specific:

    Search the existing specs and utils-*.ts for the feature, its UI labels and a similar workflow before writing any Playwright code.

    line 46
  5. Distinctive:

    When a helper almost fits, give it a sensible optional argument rather than copying it into the test.

    line 60
  6. Distinctive:

    Do not re-assert the setup (sign-in, document creation) in every test, and do not repeat a scenario that differs from an existing one by a …

    line 75

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Docs E2E tests

The Playwright tests live in src/frontend/apps/e2e/__tests__/app-impress. E2E tests are the most expensive tests of the repository: keep the suite small, run as little of it as possible, and only on Chromium.

Run

  1. The backend must be running: make run-backend (see the docs-start skill).
  2. Install only Chromium, once: yarn install-playwright chromium, from src/frontend/apps/e2e.
  3. Run the narrowest scope, from src/frontend/apps/e2e:

    yarn test __tests__/app-impress/<file>.spec.ts --project=chromium -g "<test name>"

    From src/frontend, yarn e2e:test takes the same arguments.

  • Playwright reads apps/e2e/.env (BASE_URL=http://localhost:3000) and starts the frontend itself with yarn app:dev, or reuses whatever already answers on :3000.
  • The global setup (auth.setup.ts) signs in with the seeded Keycloak users and saves their session.
  • If tests fail with HTTP 429, the throttling of the dev backend is too low: the CI raises it by appending env.d/development/common.e2e to env.d/development/common.local. Locally, remove those lines afterwards: they would keep overriding the dev limits on every later backend run.
  • Never run Firefox or WebKit (--project=firefox|webkit, yarn test:ui::firefox|webkit) unless asked. Never run the whole suite (yarn test with no file) unless asked, or after a change to the shared E2E setup.
  • For debugging, yarn test:ui::chromium opens the UI mode.

Widen only when needed: one test, then its spec file, then closely related specs.

Reuse before writing

Search the existing specs and utils-*.ts for the feature, its UI labels and a similar workflow before writing any Playwright code. The helpers often hold the synchronization a test needs (waiting for a PATCH, a save, a URL change, a collaborative update): do not replace them with the bare clicks.

filehelpers
utils-common.tscreateDoc, goToGridDoc, updateDocTitle, verifyDocName, overrideConfig, mockedDocument, mockedListDocs, openHeaderMenu, clickInDocOptionMenu, randomName
utils-editor.tsgetEditor, writeInEditor, openSuggestionMenu, mockAIResponse
utils-share.tsaddNewMember, updateShareLink, updateRoleUser, connectOtherUserToDoc
utils-signin.tsSignIn, logOut, expectLoginPage
utils-sub-pages.tscreateRootSubPage, addChild, getTreeRow, navigateToPageFromTree
utils-export.tsoverrideDocContent, comparePDFWithAssetFolder

When a helper almost fits, give it a sensible optional argument rather than copying it into the test. Do not turn a helper into a catch-all with unrelated options.

Add as little as possible

  1. Can an existing test assert the new behaviour cheaply and still read well? Extend it.
  2. Does the behaviour need E2E at all? A Vitest test next to the component, or a backend test, is often enough. E2E is for user workflows and frontend/backend integration: editing, sharing and permissions, collaboration, sub-pages, sign-in, export.
  3. Otherwise, add a focused test to the existing spec of the feature. Create a new spec file only when no feature file fits.

Do not re-assert the setup (sign-in, document creation) in every test, and do not repeat a scenario that differs from an existing one by a single action.

Write reliable tests

  • Selectors: getByRole, getByLabel, getByText, then getByTestId. No generated classes, DOM paths or indexes. Do not add a data-testid when an accessible selector is stable.
  • Waits: web-first assertions (await expect(locator).toBeVisible()), awaited responses or URL changes. No waitForTimeout to fix a race, even if older tests do it.
    • One legitimate exception: the version history groups edits by a time window (60 s by default) keyed on timestamps set by yhub, so page.clock cannot shorten it. Shrink it with overrideConfig(page, { COLLABORATION_VERSION_GRANULARITY_MS: '2000' }) and wait a real waitForTimeout longer than it between edits, as doc-version.spec.ts does.
  • Independence: a test never depends on another one or on its order, and creates only the data it needs (randomName avoids collisions).
  • Collaboration: use connectOtherUserToDoc and wait for the visible result of the remote edit, never a fixed delay.
  • A flaky test is a bug: find the missing synchronization point (missing await, unawaited request, unstable selector, shared data) instead of raising a timeout.

Before finishing

  • yarn lint in src/frontend/apps/e2e.
  • Review git diff: no unrelated test changed, helpers reused, no new sleep, no duplicated scenario.
  • Report the tests reused, modified or created (and why a new one was needed), the exact commands run, that only Chromium was used, and what was not verified. Never claim the whole suite or another browser passed without running it.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.