測試、Code Review 與 PR

返回 Codex 教學總目錄

目標與準備

本段提到的教學與資源: Git 入門

測試回答已寫出的案例是否符合期待，Review 檢查修改是否帶來遺漏的風險與行為差異，PR 則讓指定分支的成果可以被其他人審閱。三者不能互相代替；沒有發現問題不是證明不可能有問題，PR 已開啟也不表示已合併、部署或公開。這次會讓你親自看見測試覆蓋範圍的空缺。

步驟 1：建立故意有問題的提案

建立新的 codex-review-lab，複製 expected 的五個檔案，依 Git 篇用本機練習身分初始化 main 並提交五檔基準。確認工作目錄乾淨後執行下面命令建立分支。不要使用剛才仍有未完成變更的庫；在新的副本操作才能判斷本次差異來自哪裡。

git switch -c codex/review-lab
node --test core.test.mjs

原測試應 3 項全過。現在只在 core.mjs 的 visibleTasks 最後一行，把 return tasks; 改成 return tasks.reverse();，不要改其他函式。再跑同一測試，仍應全過，因為既有篩選案例只斷言 Active 與 Completed，沒有直接檢查 All 的順序。這是故意製造的待審修改，還不能提交或當成功功能使用。

git diff -- core.mjs
node --test core.test.mjs

步驟 2：選對 Review 範圍

桌面版開啟本 Git 專案，先在 Review 面板選 Unstaged，確認看到剛改的 core.mjs，再於 Codex 輸入框使用 /review，核對所選差異。CLI 先從 codex-review-lab 的系統終端機執行 codex，確認工作目錄後，在互動輸入框使用 /review，選 Review uncommitted changes；不要把 /review 打在系統 shell。此處還沒 commit，只審某個已提交版本會漏掉 reverse。入口與範圍依官方 Code review 文件核對。

桌面版另有 Staged、Commit、Branch、Last turn，不能把 Last turn 當整個分支。CLI 的未提交審查包含已暫存、未暫存與未追蹤內容，範圍比單看 git diff 更廣。Review 面板也可能呈現你或其他任務留下的改動；多 repository 時先核對選取的庫。若同一檔案既有 staged 又有 unstaged，依Git 篇的 MM 練習分別查看，再說明這次要審哪部分。

把「All 必須保留原順序且不能修改輸入」作為補充審查條件。預期的有效發現要指出目前那行 reverse、觸發條件是 All／預設分支、影響是反轉順序且原地改陣列，以及哪些測試沒涵蓋。只有「程式碼品質可改善」沒有位置和具體後果，不是本例可採取行動的發現。

Review the uncommitted change only. All must preserve task order and must not mutate the input array. Existing tests pass, so inspect their coverage rather than treating that as proof.
For each finding, state the file/line, trigger, concrete impact and a verification case. Do not edit, stage, commit or push during this review. If you find no issue, report what you examined and any uncertainty.

如果代理沒指出問題，不要把它的結論當唯一驗收；親自讀 reverse 的用法，接著用下面測試確認。若代理提出錯誤發現，也不要直接照改，要求能重現的輸入與結果。Review 的責任是提供可核對的證據；真正修改要在理解並同意修正後另行交付，保留原始問題與最後差異之間的對照。

步驟 3：補測試並移除錯誤提案

將下列內容新增為 review.test.mjs。第一項檢查 All 的原始順序，第二項用凍結陣列檢查不應嘗試原地修改。先在錯誤版執行兩個檔案，預期原三項通過、新兩項失敗；不要跳過這一步，否則不知道新測試是否真能擋住這種改動。

import test from "node:test";
import assert from "node:assert/strict";
import { visibleTasks } from "./core.mjs";

const makeTasks = () => [
  { id: "a", title: "Read", completed: true },
  { id: "b", title: "Build", completed: false },
];

test("All preserves original order", () => {
  assert.deepEqual(visibleTasks(makeTasks(), "all").map((task) => task.id), ["a", "b"]);
});

test("All does not attempt to mutate the input array", () => {
  const tasks = Object.freeze(makeTasks());
  assert.doesNotThrow(() => visibleTasks(tasks, "all"));
});

node --test core.test.mjs review.test.mjs

接著只把 visibleTasks 最後一行恢復為 return tasks;，保留新測試，再跑應 5 項全過。檢查 git diff：core.mjs 應已回到 main 基準，最終要交付的只有新增 review.test.mjs。這次 Review 阻止了錯誤實作進入提交，同時留下之前缺少的保護；PR 要描述最終的測試補強，不能宣稱程式碼仍有不存在的修正。

步驟 4：整理可審閱的提交與 PR 草稿

只暫存新測試，先看清單與內容再提交。接著用 branch diff 核對 main 到本分支只有 review.test.mjs，檢查命令結果是這個最終版本。若又修改檔案，先重跑受影響測試，不能引用較早版本的全過記錄。下面 PR 文字中的結果只在你真的執行後才能保留。

git add review.test.mjs
git diff --cached --name-only
git diff --cached -- review.test.mjs
git commit -m "Test All filter order and input preservation"
git diff --stat main...HEAD
git status --short

Title: Add regression coverage for All filter ordering and input preservation

The existing filter tests cover Active and Completed but miss All ordering and input mutation. Add two focused cases so a reversing implementation is rejected. Production code is unchanged.

Validation: node --test core.test.mjs review.test.mjs — 5 passed, if actually run.
The deliberate reverse variant fails both new tests.
Browser checks: NOT RUN in this test-only change unless separately verified.
Deployment: not performed.

這時本機交付已具體可審，還沒有 GitHub PR。若要練習外部 PR，在自己的 GitHub 建立空白練習庫，不預先加入 README，複製它實際顯示的遠端網址，再把下面第一行的占位符換成該網址後執行。先核對 remote -v 確實是自己的新庫；後面兩次 push 會把本機基準與測試分支傳到 GitHub。

git remote add origin YOUR_REPOSITORY_URL
git remote -v
git push -u origin main
git push -u origin codex/review-lab

在 GitHub 的 Pull requests 選 New pull request，base 選 main、compare 選 codex/review-lab，檢查 Files changed 只有測試，再貼上整理好的標題與說明，選 Create pull request；仍要討論可用 draft 狀態。沒有設定 CI 的練習庫不會憑空出現測試檢查，有 CI 時要核對它檢查的是目前 head。這一步可先停在 PR，合併與部署各自依專案流程處理。

讓測試紀錄對應到最後版本

完成本機提交後，暫停其他會改這個練習庫的任務，逐行執行下列命令。前後 HEAD 應相同、status 應乾淨、分支應為 codex/review-lab、main...HEAD 應只有 review.test.mjs，測試應 5 過 0 敗且沒有跳過項目。把實際 SHA 和輸出附在交付紀錄。HEAD 相同但檔案還有修改時，測試其實包含未提交內容，不能把結果全算到那個 commit 上。

git branch --show-current
git rev-parse HEAD
git status --short --untracked-files=all
git diff --name-only main...HEAD
node --test core.test.mjs review.test.mjs
git rev-parse HEAD
git status --short --untracked-files=all

依 Git diff 官方說明，main...HEAD 從兩者共同祖先比較到 HEAD；它不會把尚未提交的修改算進去。因此新增 review.test.mjs 但還沒 git add 時，普通 diff 可能空白，仍要看 status 並開檔審查。這裡使用本機 main；正式 PR 要核對實際 base、head 和該 head 的 CI。看到 skipped、cancelled 或測試尚未完成，都分開記錄，不以綠色圖示取代檢查範圍。

常見問題、還原與驗收

驗收要保留原三測試漏失問題、新兩測試抓到問題、最終五測試通過的對照，以及只有測試檔的提交。想重做就在同一獨立練習重新引入 reverse，確認失敗後再恢復，不刪除整個 Git 庫或改寫公開歷史。若已開練習 PR 而決定不合併，可在 GitHub 關閉它並保留討論。圖中 1 是測試證據，2 是審查判斷，3 是可核對交付；本篇未替你執行模型 Review、GitHub 推送或公開操作。

返回 Codex 教學總目錄

閱讀完整文字說明

Tests to Review to PR

• AI 工具
• 教學
• Codex