Stats
Actions
Tags
Help us improve
Share bugs, ideas, or general feedback.
From ddd-workflow
Plans and writes E2E tests using Playwright, supporting Greenfield (spec-driven) and Retrofit (existing project) modes. Engages user for ambiguous decisions.
npx claudepluginhub applepig/ddd-workflowHow this skill is triggered — by the user, by Claude, or both
Slash command
/ddd-workflow:ddd.e2eThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
在 main agent context 中執行 E2E 測試的規劃與撰寫。**不是 subagent**——全程可以跟使用者對話，在判斷點暫停確認。
Build E2E test specs for critical user journeys — Playwright or Cypress, page objects, setup/teardown, CI config. Use when asked to "write E2E tests", "end-to-end testing", "browser tests", "UI tests", or "Playwright tests".
Writes new Playwright E2E tests following project conventions, with POM/business-layer architecture, network-aware stability patterns, and quality validation.
Configures and writes end-to-end tests with Playwright or Cypress for validating user flows, browser integration, CI E2E tests, acceptance tests, and production smoke tests.
Share bugs, ideas, or general feedback.
在 main agent context 中執行 E2E 測試的規劃與撰寫。不是 subagent——全程可以跟使用者對話，在判斷點暫停確認。
E2E 測試充滿灰色地帶：
這些判斷需要使用者參與。Subagent 無法暫停發問，會傾向走阻力最小的路——縮減測試來「通過」。
撰寫測試時，根據需要查閱以下參考文件：
| 文件 | 內容 | 何時查閱 |
|---|---|---|
| playwright-patterns.md | Locator 優先級、等待策略、waitForResponse 驗證、debounced 搜尋、re-render 陷阱 | 撰寫或除錯測試程式碼時 |
| test-architecture.md | 目錄結構、Page Object 模式、前置資料策略、測試結構範例 | 建立新測試檔案或 Page Object 時 |
| quality-principles.md | 品質防線 5 條原則與實戰踩坑經驗 | 遇到判斷困難、品質檢查、或 spec/reality 不一致時 |
根據上下文判定模式：
spec.md 且包含 E2E 相關驗收條件 → 從 spec 驅動從 spec.md 找出所有適合 E2E 驗證的驗收條件。
判斷標準——適合 E2E 的：
不適合 E2E 的（用 unit/integration test）：
對每個驗收條件，規劃：
## 測試案例：<功能名稱>
### Happy Path
- [ ] <使用者操作步驟> → <預期結果>
### Edge Cases
- [ ] <邊界條件> → <預期結果>
### Error Cases
- [ ] <錯誤情境> → <預期結果>
決策點 1：向使用者展示測試案例清單，使用 AskUserQuestion 確認。
確認項目：
逐一撰寫已確認的測試案例。每個測試完成後執行，確認結果。
撰寫前先查閱 test-architecture.md 了解目錄結構與 Page Object 模式，撰寫過程中參考 playwright-patterns.md 的 locator 和等待策略。
如果碰到 spec 與實際行為不符：
⚠️ Spec/Reality 不一致
spec.md 說：「送出表單後應顯示成功訊息」
實際行為：送出後導向到列表頁，沒有成功訊息
請判斷：
1. 這是 bug → 我寫測試驗證 spec 的預期行為（目前會 fail，標 test.fixme）
2. spec 過時 → 我依實際行為寫測試，並建議更新 spec
3. 需要更多資訊 → 我先跳過，繼續下一個
絕對不做的事：悄悄把測試改成符合 code。
# Playwright 是否已安裝？
npx playwright --version 2>/dev/null || echo "NOT_INSTALLED"
# playwright.config 是否存在？
ls playwright.config.{ts,js} 2>/dev/null || echo "NO_CONFIG"
# 現有測試的位置和數量
find . -path "*/e2e/*.spec.*" -o -path "*/e2e/*.test.*" | head -20
# 現有 Page Object
find . -path "*/e2e/pages/*" -o -path "*/e2e/pom/*" | head -20
如果環境不完整，先列出缺少的部分，跟使用者確認設定方向再繼續。
用瀏覽器探索 app，建立功能地圖：
# 偵測 dev server
# 檢查常見 port：3000, 3001, 5173, 8080, 4200, 8000
for port in 3000 3001 5173 8080 4200 8000; do
curl -s -o /dev/null -w "%{http_code}" http://localhost:$port/ 2>/dev/null | grep -q "200\|301\|302" && echo "Found: http://localhost:$port"
done
探索時記錄：
決策點 2：向使用者展示功能地圖，確認：
每批：
這樣避免一次規劃太多、寫到一半發現方向錯誤。
每輪測試撰寫完畢後，自我檢查（原則說明見 quality-principles.md）：
waitForTimeout？networkidle 或 waitForResponse 等穩定再操作表單？waitForResponse 有驗證 URL query params，不只檢查 path？save() / click() + waitForResponse 用 Promise.all 防止快回應被漏掉？所有確認過的測試案例都已撰寫並通過執行，回報使用者最終結果。