菜单
Decide when end-to-end tests pay off, how to budget flake, and how to split smoke vs full regression suites. Use when asked "should we add an E2E test for this?" or when an E2E suite has grown too slow or too flaky to trust.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Expert guidance on detecting mobile performance regressions — startup time, frame jank, scroll performance, binary size — with baselines and noise-aware thresholds. Use when setting up perf gates in CI or when a release is suspected of regressing.
Measure code coverage honestly across mobile stacks — JaCoCo (JVM), llvm-cov (iOS), lcov (Flutter), Jest (RN) — and report it to Codecov / Coveralls without chasing meaningless numbers. Use when setting up coverage or when asked to raise a coverage gate.
Expert guidance on running mobile test suites in CI — matrix design, caching, sharding, artifacts, required checks — without paying for slow, flaky runs. Use when configuring GitHub Actions, GitLab CI, Bitrise, or Codemagic for mobile testing.
Expert guidance on automated and manual accessibility testing for mobile apps — Espresso AccessibilityChecks, XCTest accessibility audits, Flutter a11y guidelines, RN a11y assertions. Use when adding a11y coverage or when asked how to catch accessibility regressions in CI.
Expert guidance on snapshot / golden image testing across mobile stacks — Paparazzi (Android), swift-snapshot-testing (iOS), golden_toolkit (Flutter), and RN snapshot tests. Use when asked to lock down UI visuals or catch unintended rendering regressions.
Compare and apply UI test tooling across mobile — Espresso, XCUITest, flutter_test / integration_test, Detox, and Maestro. Use when deciding which UI test layer fits a feature and how to structure selectors, waits, and page objects.
| name | e2e-testing-strategy |
| description | Decide when end-to-end tests pay off, how to budget flake, and how to split smoke vs full regression suites. Use when asked "should we add an E2E test for this?" or when an E2E suite has grown too slow or too flaky to trust. |
E2E tests exercise the whole app against real (or near-real) backends on a real device. They are the most realistic and the most expensive layer: slow, flaky-prone, and high-maintenance. Keep them small, keep them critical, and budget their flake explicitly.
E2E is uniquely good at catching:
It is a bad tool for asserting logic edge cases, field validation, or API response shapes. Those belong in unit, integration, and contract tests.
Ask these questions in order. Add the test only when the answer to all is yes:
If the answer is no to any, cover it at a cheaper layer.
Split the E2E suite into two tiers with different cadences:
Flag tests with @Smoke / @Regression and filter in CI via tags (--filter, -DincludeTags=Smoke, Maestro tags:).
A suite of 100 E2E tests each 99 % reliable passes end-to-end only 37 % of the time. Two options:
flaky-test-reduction skill).Set an explicit flake budget, for example: "any test flaking more than 0.5 % over the last 100 runs is quarantined within 24 h". Track it in your CI dashboard.
Real "end-to-end" is a spectrum. Move the dial left (more hermetic) where possible:
e2e+$runId@example.com).Be aggressive. Delete an E2E test when:
Keeping dead E2E tests around erodes trust in the suite as a whole.