agentsclimarketplace
Sign in

Fec e2e testing

Skill bovinphang/frontend-craft/skills/fec-e2e-testing

Use when creating, maintaining, debugging, or reviewing real-browser end-to-end tests with Playwright or Cypress, including Page Object models, CI artifacts, traces, flaky tests, cross-page visual regression, and critical user journeys such as login, payment, permissions, or CRUD. For layer planning or tests close to UI components, choose the matching testing workflow first; Chinese triggers include E2E, end-to-end testing, Playwright, Cypress.From its SKILL.md

Install
npx -y skills add bovinphang/frontend-craft --skill fec-e2e-testing

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 21 stars21 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.4 KB, 617 tokens by cl100k_base, as published. Nobody here has run it

E2E Test Specification

Purpose

Validate key user journeys with real browsers and uncover integration risks not covered by unit tests.

Procedure

  1. Clarify the key journeys: cross-page processes such as login, purchase, creation, search, permissions, payment, etc. are given priority; if you only choose the test level, do the test hierarchical planning first.
  2. New projects will be given priority by Playwright; existing Cypress projects will continue to use Cypress and will not be migrated for the sake of migration.
  3. Use Page Object or fixtures to encapsulate login, page locator and shared data, and avoid naked selectors in the spec.
  4. Assert that the user can see the results, relying on Locator automatic waiting, network response or visible status, without using fixed sleep.
  5. CI must upload HTML report, screenshots, trace or video; Flaky use cases must be isolated, reproduced, marked with sources and associated with issues.
  6. When debugging fails, read the trace, console, network and screenshots first, and then change the test; do not misjudge real product defects as flaky.
  7. Record the test environment, seed data and cleanup strategies for key browser capabilities, payment, permissions, uploads and real-time communication processes.
  8. Test data must be repeatable: API seeds, database fixtures, test accounts or mock services are preferred; random data must have a unique prefix and be cleaned in teardown.

Detailed reference

Constraints

  • Disable reliance on sleep / fixed setTimeout as primary synchronization means.
  • Do not run real E2E in production environment.
  • Avoid asserting component internal pixel-level styles in E2E; cross-page screenshots/visual regressions only cover key page states in the user journey.
  • Failure must be able to be located by taking screenshots, traces or videos.
  • Component internal contract testing is offloaded to component testing workflow.
  • Do not bring unstable waits, random data, or dependent test order into CI.
  • Do not treat the number of retries as flaky management; retries can only retain evidence, and the root cause still needs to be located.

Expected Output

Key user journeys have stable E2E coverage, failed products can locate problems, and reports and traces in CI can be downloaded; flaky use cases include recurrence commands, isolation strategies, and follow-up issues.

What ships with it: 4 files

7.7 KB alongside SKILL.md

references/

Gives 0 of the 12 instructions most e2e browser skills give in 617 tokens

Counted across 499 of the 513 authors here whose files we hold, read 2026-09-06

  • Capture screenshots, videos, and traces on failurein 32 of 499, across 23 files
  • Close the browser when donein 22 of 499
  • Interact with elements using snapshot refsin 21 of 499, across 20 files
  • Wait for specific network responses instead of fixed timeoutsin 20 of 499, across 10 files
  • Keep tests independent with no shared statein 19 of 499, across 17 files
  • Use Page Object Model classes to encapsulate page interactionsin 19 of 499, across 9 files
  • Locate elements with data-testid attributesin 19 of 499, across 10 files
  • Quarantine flaky tests with fixme or skipin 17 of 499, across 7 files
  • Upload test artifacts after every CI runin 17 of 499, across 8 files
  • Wait on conditions instead of using fixed sleepsin 17 of 499, across 13 files
  • Clean up test data after each testin 17 of 499, across 16 files
  • Test user-visible behavior, not implementation detailsin 16 of 499, across 10 files

Said here and by no other author read

  • Clarify key user journeys before writing tests
  • Prefer Playwright for new projects
  • Use Page Objects or fixtures for shared locators
  • Assert on user-visible results using automatic waiting
  • Read traces, console, network before changing failing tests
  • Keep test data repeatable via seeds, fixtures or mocks

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.