agentsclimarketplace
Sign in

Fec testing strategy

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

Use when planning or reviewing a frontend testing strategy, selecting the right test layer by risk, mapping coverage across static checks, unit tests, component tests, integration tests, E2E, Storybook/visual regression, a11y, security, performance, or CI gates. Do not use to write individual component/E2E tests or merely run existing validation commands; Chinese triggers include test strategy, test layering, test plan, coverage matrix.From its SKILL.md

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

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

4.0 KB, 705 tokens by cl100k_base, as published. Nobody here has run it

Front-end testing strategy

Purpose

Choose your testing approach by “closeness to code/level of risk coverage” to avoid cramming all risks into component tests or E2E.

Procedure

  1. Identify the type of change: pure logic, UI components, cross-module processes, browser capabilities, visual stability, dedicated quality risks, or release gates.
  2. Establish a test level matrix, at least distinguish:
    • Static checking: TypeScript, ESLint, format, dependency security, build.
    • Unit testing: utils, hooks/composables, state logic, schema, pure functions.
    • Component testing: props/emits, user interaction, loading/error/empty, mock boundaries.
    • Lightweight integration testing: form + API mock + routing/Store/Provider context.
    • E2E: real browser, cross-page key journeys, authentication, payments, permissions, CI artifacts.
    • Visual/interactive documentation: Storybook interaction, Chromatic, visual regression baseline.
    • Special quality: a11y, security, performance, compatibility.
  3. Allocate coverage by risk: high-frequency core paths prioritize E2E, complex component status prioritizes component testing, pure logic prioritizes unit testing, and lightweight integration testing is used for cross-provider collaboration.
  4. Use the testing pyramid to control maintenance costs:
    • The closer to pure logic, the more tests, the faster, and the more stable it is.
    • E2E only covers key user journeys and real browser risks, not every branch.
    • Vision, a11y, safety and performance belong to dedicated quality layers and are not included in ordinary component tests.
  5. Check whether commands, test frameworks, directory conventions, and CI gates already exist; use the current status of the project and do not introduce unnecessary tools to the policy document.
  6. Plan failure evidence: Each high-risk item should describe how to locate it when it fails, such as assertions, screenshots, traces, coverage, logs, or reports.
  7. Design test data and mock strategies: share fixtures to express business scenarios, and the test data builder only encapsulates noise fields to avoid handwriting random objects for each test.
  8. Manage flaky risks: Mark time, network, animation, nonce, concurrency, and external services as sources of instability, and specify isolation, retries, and evidence artifacts.
  9. Output the minimum executable test plan: what is covered by each layer, what is not covered, priority, recommended commands and responsibility skills.

Constraints

  • Don't write the test strategy as a general "write more tests"; each suggestion must correspond to a specific risk.
  • All projects are not required to complete the complete testing pyramid; they are tailored according to business risks and team maintenance capabilities.
  • Do not consider E2E as a replacement for unit/component testing; do not consider component testing as a guarantee of true browser compatibility.
  • Do not force the introduction of new frameworks for small changes; give priority to reusing existing tools and scripts in the warehouse.
  • Do not pursue coverage figures without risk explanation; coverage can only assist judgment and cannot replace scene coverage.
  • Do not include random fixtures, shared global state, or tests that depend on execution order into trunk gates.

Expected Output

Output test layering recommendations, mapping of risks to test layers, priorities, recommended commands, the scope of test files that need to be added or adjusted, and the specific skills or agents that need to be clearly diverted.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most roadmap strategy skills give in 705 tokens

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

  • Check for product marketing context firstin 39 of 614, across 16 files
  • Use compact with a custom summaryin 32 of 614, across 16 files
  • Compact after planningin 30 of 614, across 16 files
  • Do not compact mid-implementationin 30 of 614, across 17 files
  • Structure launch marketing across three channel typesin 21 of 614, across 5 files
  • Read the compaction suggestionin 20 of 614, across 10 files
  • Write before compactingin 17 of 614, across 11 files
  • Write important context to files before compactingin 16 of 614, across 5 files
  • Recruit early users one-on-onein 16 of 614, across 3 files
  • Identify 3-5 core content pillarsin 15 of 614, across 9 files
  • Target a specific keyword or questionin 14 of 614, across 4 files
  • Stagger announcements to maintain momentumin 14 of 614, across 4 files

Said here and by no other author read

  • Establish a test level matrix
  • Check existing commands and frameworks
  • Plan failure evidence
  • Design test data and mock strategies
  • Manage flaky risks
  • Output the minimum executable test plan

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.