Testing / CI：不要靠「我剛剛手動看起來可以」

Learning outcomes

• 能區分 unit/integration/E2E 的 boundary。
• 能解釋 CI runner 與本機環境差異。
• 能設計 fail-fast gate 順序。
• 能說明 CI PASS 為何不等於 production PASS。

1. Unit Test

input: score = 60
expected:
isPassed(score) === true

適合純規則與 boundary cases。

2. Integration Test

POST /courses
  ↓ route
  ↓ validation/auth
  ↓ service
  ↓ test database
  ↓ 201 + row exists

驗證多個真實 components 能協作。

3. E2E

Browser:
login
→ create course
→ reload
→ course still visible

成本較高，因此通常保護少量 critical journeys。

4. CI Pipeline

checkout
→ install
→ syntax/lint
→ unit/integration
→ build
→ artifact verify

便宜快速的 checks 先跑，讓 failure 盡量早出現。

5. Production 還要 Smoke

CI runner 不是 production。Deploy 後還要驗公開 URL、route、env、external dependency。

6. 怎麼選測試層級

不要把所有情境都往最昂貴的 E2E 塞。先問「這個 contract 最小在哪一層能被可靠驗證？」純計算規則放 unit；route 與資料庫協作放 integration；只有真正需要 Browser、navigation、render 的 critical journey 才放 E2E。

Pure rule?
→ unit

HTTP + auth + DB?
→ integration

Real Browser journey?
→ E2E

這樣做的目的不是追求某種測試金字塔比例，而是讓 feedback 速度、failure localization 與真實性取得平衡。

7. Flaky Test 也是需要 Debug 的 Failure

同一份 code 有時 pass、有時 fail，常見原因包括 shared state、未等待 async、真實網路、時間/randomness、資料沒有隔離。不要用「rerun 到綠」把 flakiness 當作不存在。

Project checkpoint：Course Workspace Quality Pipeline

rule tests
API integration
critical E2E
CI gates
build artifact
deploy
production smoke

Debug evidence：Workflow 紅了

先找第一個 failure step，不要只看 workflow 整張紅色卡片。若 syntax step 已 fail，後面 deploy 根本還沒開始。