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

💬 E2e

e2e

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.

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

📺 まず動画で見る(YouTube)

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

※ 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-18
同梱ファイル
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.