jpskill.com
💬 コミュニケーション コミュニティ 🟢 非エンジニアでもOK 👤 管理職・人事・カスタマー対応

💬 E2e

e2e

??ステム全体がユーザーの操作通りに機能するかを確認する

⏱ お礼メール定型化 5分/通 → 30秒/通

📺 まず動画で見る(YouTube)

▶ 【最新版】Claude(クロード)完全解説!20以上の便利機能をこの動画1本で全て解説 ↗

※ jpskill.com 編集部が参考用に選んだ動画です。動画の内容と Skill の挙動は厳密には一致しないことがあります。

📜 元の英語説明(参考)

Use when running e2e tests, debugging test failures, or fixing flaky tests. Covers failure taxonomy, fix rules, and workflow. Never changes source code logic or API without spec backing.

🇯🇵 日本人クリエイター向け解説

一言でいうと

??ステム全体がユーザーの操作通りに機能するかを確認する

※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。

⚡ おすすめ: コマンド1行でインストール(60秒)

下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。

🍎 Mac / 🐧 Linux
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o e2e.zip https://jpskill.com/download/4024.zip && unzip -o e2e.zip && rm e2e.zip
🪟 Windows (PowerShell)
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/4024.zip -OutFile "$d\e2e.zip"; Expand-Archive "$d\e2e.zip" -DestinationPath $d -Force; ri "$d\e2e.zip"

完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。

💾 手動でダウンロードしたい(コマンドが難しい人向け)
  1. 1. 下の青いボタンを押して e2e.zip をダウンロード
  2. 2. ZIPファイルをダブルクリックで解凍 → e2e フォルダができる
  3. 3. そのフォルダを C:\Users\あなたの名前\.claude\skills\(Win)または ~/.claude/skills/(Mac)へ移動
  4. 4. Claude Code を再起動

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

  1. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
    • · macOS / Linux: ~/.claude/skills/
    • · Windows: %USERPROFILE%\.claude\skills\

Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。

詳しい使い方ガイドを見る →
最終更新
2026-05-17
取得日時
2026-05-17
同梱ファイル
1

💬 こう話しかけるだけ — サンプルプロンプト

  • E2e で、お客様への返信文を作って
  • E2e を使って、社内向けアナウンスを書いて
  • E2e で、メールテンプレートを整備して

これをClaude Code に貼るだけで、このSkillが自動発動します。

📖 Claude が読む原文 SKILL.md(中身を展開)

この本文は AI(Claude)が読むための原文(英語または中国語)です。日本語訳は順次追加中。

E2E Testing

Failure Taxonomy

Every e2e failure is exactly one of:

A. Flaky (test infrastructure issue)

  • Race conditions, timing-dependent assertions, stale selectors, missing waits
  • Symptom: passes on retry, fails intermittently

B. Outdated (test no longer matches implementation)

  • Test asserts old behavior that was intentionally changed; selectors reference removed elements
  • Symptom: consistent failure, app works correctly

C. Bug (implementation doesn't match spec)

  • Test correctly asserts spec'd behavior, code is wrong
  • Only classify as bug when a spec exists to validate against
  • If no spec exists, classify as "unverified failure" and report to the user

Fix Rules by Category

Flaky fixes:

  • Replace waitForTimeout with auto-waiting locators
  • Replace brittle CSS selectors with getByRole/getByLabel/getByTestId
  • Fix race conditions with expect() web-first assertions
  • Fix mock/route setup ordering (before navigation)
  • Never add arbitrary delays - fix the underlying wait
  • Never add retry loops around assertions - use the framework's built-in retry

Outdated fixes:

  • Update test assertions to match current (correct) behavior
  • Update selectors to match current DOM/API
  • Never change source code - the implementation is correct, the test is stale

Bug fixes:

  • Quote the spec section that defines expected behavior
  • Fix the source code to match the spec
  • Unit tests MUST exist before the fix is complete — write them first if missing (TDD)
  • Never change e2e assertions to match buggy code
  • Never change API contracts or interfaces without spec backing
  • If no spec exists, ask the user: bug or outdated test?

Source Code Boundary

E2e test fixes must not change application logic, API contracts, database schemas, or configuration defaults. The only exception: bug fixes where a spec explicitly defines the correct behavior and unit tests cover the fix.

Workflow

Step 1: Discover Test Infrastructure

  1. Find e2e config: playwright.config.ts, vitest.config.ts, or project-specific setup
  2. Read package.json for the canonical e2e command
  3. Check if dev server or Tilt environment is required and running
  4. Find spec files: *.spec.md, docs/*.spec.md - source of truth for bug decisions

Step 2: Run Tests

# Playwright
yarn playwright test --reporter=line

# Or project-specific
yarn test:e2e

Parse failures into:

Test File Error Category
login flow auth.spec.ts:42 timeout waiting for selector TBD

Step 3: Categorize

For each failure: read the test file, read the source code it exercises, check for a corresponding spec file, assign category (flaky / outdated / bug / unverified).

Step 4: Fix by Category

Apply fixes in order: flaky first (unblocks other tests), then outdated, then bug.

Step 5: Re-run and Report

## E2E Results

**Run**: `yarn test:e2e` on <date>
**Result**: X/Y passed

### Fixed
- FLAKY: `auth.spec.ts:42` - replaced waitForTimeout with getByRole wait
- OUTDATED: `profile.spec.ts:88` - updated selector after header redesign
- BUG: `transfer.spec.ts:120` - fixed amount validation per SPEC.md#transfers

### Remaining Failures
- UNVERIFIED: `settings.spec.ts:55` - no spec, needs user decision

### Unit Tests Added
- `src/transfer.test.ts` - amount validation edge cases (covers BUG fix)

See testing-best-practices for async handling, flake classification, and preflight check patterns.