SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsui-test-testcafe

ui-test-testcafe

Testing & quality

View repository

Updated 10-16 01:34

About this skill

TestCafe UI automation testing

English version: see the matching English skill.

When to use

  • When you need to output a test plan or automation design oriented to TestCafe UI automation testing workflows.
  • The project already uses the relevant tools, or you want a tool-specific plan that can be directly implemented.

Output format options

Markdown is used by default. Unless the request explicitly requires another format, do not extend the output format.

How to use

  1. Open prompts/ui-test-testcafe.mdand use it as the main prompt.
  2. Supplement with real project context: scope, environment, constraints, risks, dependencies, and expected deliverables.
  3. If the input is incomplete, first return a usable first version and mark the missing information and assumptions.

Reference files

  • When calibrating domain results, correct comparisons, or evidence gaps, read references/domain-decision-example.md 's desensitized input, item-by-item expectations, and recalculation basis.

  • prompts/ui-test-testcafe.md: the main prompt for this skill.

  • references/framework-spec.md: tool-specific structure and coverage description.

  • references/setup-and-ci.md: installation, execution, and CI description.

  • examples/sample-context.md: example request context.

  • scripts/run-tests.sh: lightweight local execution entry point.

Domain execution key points

  1. Confirm the project's TestCafe/Node/browser, native automation mode, and CI/reporter versions; generate fixtures/tests/config that are compatible with the existing runner, and leave missing configuration pending confirmation without recommending implicit upgrades.
  2. Initialize isolated sessions with Role or independent identities, and isolate accounts/business keys in the same way; asynchronous t actions must be awaited, and Selector/assertions should use supported smart waits rather than fixed sleeps.
  3. Verify post-payment status, amount, and entity; stubbing external boundaries must not bypass the UI under test, a normal title cannot represent success, and negative controls should make business assertions fail.
  4. A non-zero CLI exit or a programmatic runner returning failedCount>0 must fail CI; custom reporters must not swallow failures, and screenshots/console/test IDs and cleanup must be retained. Record static parseability and actual execution separately.

Common misconceptions

  • Do not directly give a generic plan when the scope is vague and context is missing.
  • Do not treat all modules and scenarios as equally important.
  • Do not skip assumptions and missing-information explanations.

Best practices

  • Start from the prompt file and only supplement context that truly affects the result.

  • Keep the output risk-driven and directly usable for execution or review.

  • When information is incomplete, first provide a usable version, then clearly mark the gaps.

  • When verifying the business assertions, failure propagation, or isolation of generated assets, read evals/fixtures/checkout-app/README.mdand use local good/bug/timeout comparisons; execute only under an explicit runtime.