ライフスタイル

テスト・コードレビュー・PR

テストは条件下の動作、レビューは変更の問題、PR は統合候補を扱います。テスト成功、承認、マージは別の状態です。

読了目安 15 分 · 操作 30 分

作業の流れを表す図です。製品画面の画像ではありません。
画像:Mokaair (© Mokaair)
総目次へ:Codex 学習ガイド:全記事の目次

実践 · Desktop / CLI / VS Code / JetBrains / cloud

この記事の目次
  1. 目標と準備
  2. 手順1:問題のある提案を用意
  3. 手順2:正しい Review 範囲を選ぶ
  4. 手順3:テスト追加と誤変更の除去
  5. 手順4:確認可能な commit と PR 下書き
  6. 検証記録を最終版に結び付ける
  7. 対処、復元と受入

目標と準備

この段落の教材・資料:

テストは書かれた事例、Review は見落とした影響、PR は分岐成果の確認です。互いに代替せず、指摘なしは無欠陥保証ではなく、PR 作成は merge/公開ではありません。今回は網羅の穴を実際に確認します。

手順1:問題のある提案を用意

新しい codex-review-lab に expected 5ファイルを置き、Git 基礎のローカル練習身分で main 基準を commit します。無変更確認後、次の分岐を作ります。未完了変更のある庫を流用しません。

ターミナル:Review 用ブランチと基準 · sh
git switch -c codex/review-lab
node --test core.test.mjs

3成功後、visibleTasks の最後だけ return tasks.reverse(); に変えます。既存は Active/Completed だけなので再実行も3成功です。意図的な未審査提案で、まだ commit や正常機能にはしません。

ターミナル:既存テストの不足を確認 · sh
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 を選択します。システムのシェルには入力しません。まだコミットしていないため、特定コミットの審査では reverse を見落とします。入口と範囲は公式 Code review 文書を参照してください。

アプリには Staged、Commit、Branch、Last turn もあり、Last turn はブランチ全体ではありません。CLI の未コミット審査はステージ済み、未ステージ、未追跡を含み、git diff だけより広い範囲です。Review パネルには自分や別タスクの変更も表示されるため、複数 repository では対象を確認します。同じファイルに両方の変更がある場合は、で別々に確認してから審査範囲を指定します。

All の順序維持と入力不変を補足します。有効な指摘は reverse の行、All 条件、順序逆転と配列直接変更、未網羅テストを示します。位置や影響のない抽象的品質改善では不十分です。

Codex への依頼:読み取り専用 Review · text
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 順序と凍結配列による不変を確認します。誤版で元3成功、新2失敗を先に確認し、新テストが本当に検出するかを見ます。

新規ファイル:review.test.mjs · javascript
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"));
});
ターミナル:回帰テスト一式を実行 · sh
node --test core.test.mjs review.test.mjs

最後の行だけ return tasks; に戻し、新テストを残して5成功を確認します。core.mjs は main と一致し、追加テストだけが成果です。PR は最終のテスト補強を説明し、差分にないコード修正を主張しません。

手順4:確認可能な commit と PR 下書き

新テストだけステージし内容確認して commit、main との差分が一ファイルか確認します。追加編集後は影響テストを再実行し、旧版成功を引用しません。次の下書き結果は実測後だけ残します。

ターミナル:最終テスト差分をコミット · sh
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
文書テンプレート:PR のタイトルと説明 · markdown
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.

ローカル成果は確認可能ですが PR はまだありません。任意練習は README なしの空 GitHub 庫を作り、実際の URL にプレースホルダーを置き換えます。remote -v が自分の新庫か確認後、二つの push で基準とテスト分岐を送ります。

ターミナル用テンプレート:リモート URL を置換してから push · text
git remote add origin YOUR_REPOSITORY_URL
git remote -v
git push -u origin main
git push -u origin codex/review-lab

GitHub で New pull request、base main、compare codex/review-lab を選び、テストだけの差分と説明を確認して作成します。議論中なら draft を使います。CI は設定済みの場合だけで、現在 head の検査か確認します。merge と公開は別工程です。

検証記録を最終版に結び付ける

ローカルコミット後、この練習庫を変更し得る別タスクを止め、次のコマンドを1行ずつ実行します。前後の HEAD は同じ、status はクリーン、ブランチは codex/review-lab、main...HEAD は review.test.mjs のみ、テストは5件通過でスキップなしが期待結果です。実際の SHA と出力を記録します。HEAD が同じでもファイルが変更されていれば、テストは未コミット内容を含むため、そのコミットだけの結果とは言えません。

ターミナル:テスト対象の版と最終差分を確認 · sh
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 を確認し、スキップ、中止、未完了を分けて記録します。緑のアイコンだけで確認範囲を判断しません。

対処、復元と受入

現象必要な証拠
成功テストでも誤動作新事例の前失敗・後成功
差分が見えない未確定/commit/base 範囲
指摘に理由がない位置、条件、最小再現
PR に無関係ファイルstage、起点、base/compare
CI 不在・旧版workflow と head SHA
追加編集最終差分を再検証

元3件の見落とし、新2件の検出、最終5成功とテストだけの commit を残します。再実行は独立教材で reverse を再導入して戻し、Git 削除や公開履歴改変はしません。不要な教材 PR は議論を残して閉じます。図1証拠、2判断、3引渡しです。読者のモデル Review/push/公開は未実行です。

21. テスト・コードレビュー・PR — 作業の流れを表す図です。製品画面の画像ではありません。 Tests → Review → PR
21. テスト・コードレビュー・PR — 作業の流れを表す図です。製品画面の画像ではありません。 Tests → Review → PR · 画像:Mokaair (© Mokaair)
詳しい説明を読む

Tests to Review to PR

総目次へ

  • ライフスタイル

    Codex 学習ガイド:全記事の目次

    導入と最初のタスクから MD の指示、高度な連携まで、60 レッスン・十単元を予定しています。習熟度、環境、目的、コマンドで次の記事を探せます。未公開の記事には状態を表示します。

  • ライフスタイル

    Worktree とタスクの分離

    Worktree は一つの Git リポジトリに別ブランチの作業場所を作ります。ファイルは分かれても DB、ポート、外部サービスは共有される場合があります。

  • ライフスタイル

    実践:小さな Web サイトを作る

    brief.md から Small Steps のタスクサイトを計画・制作し、追加、完了、削除、絞り込み、ローカル保存を実装します。HTML、CSS、データ関数、画面イベント、テストを分け、Node とブラウザーで検証して再起動・復元の手順を残します。

  • ライフスタイル

    使用量と効率:やり直しを減らす

    条件、モデル設定、時間、成果を記録し、不要な再試行と過剰な文脈を減らします。

最新の旅の情報・ガイド

出典

ライフスタイル