第13章 テストとコード品質

この章では、作った機能が変更後も壊れていないことを説明するための「テスト」と、変更を続けやすくするための「コード品質」を学ぶ。ここでは、研修の外でもそのまま通用する一般的な用語を、支援ステータス機能（メンターが担当受講者の支援ステータスを一覧で見て、必要なら更新する小さな機能）の例で詳しく解説する。

テスト戦略

• 読み：テストせんりゃく（test strategy）
• 一言で言うと：何をどのテストで確認するかを先に決める短い方針。
• くわしく：すべてを確認することはできないので、壊れると困るふるまいと起きやすい失敗を先に選ぶ。テスト戦略は、守りたいふるまい、テスト観点、自動化するもの、手動確認に残すものを決める作業である。テストの数から始めるのではなく、守るふるまいから始めると、保守コストだけ増えるテストを避けられる。先にリスクを選ぶことで、限られた時間で効果の高い確認に集中できる。
• 具体例：支援ステータス機能では、「担当外メンターが更新できてしまう」「不正なstatusが保存される」「保存失敗を利用者へ伝えられない」といったリスクを先に選び、それぞれをどの種類のテストで見るかを決める。
• つまずきやすい点：「テストを10件書く」のように数を目標にすると、守りたいふるまいと結びつかないテストが増えてしまう。
• 関連語：テストケース（第13章）、テストピラミッド（第13章）
• テキスト本文での登場箇所：第13章「テスト戦略は、先にリスクを選ぶ作業である」

テストケース

• 読み：テストケース（test case）
• 一言で言うと：前提、操作、期待結果をそろえた、実行できる一つの確認項目。
• くわしく：テスト観点はまだ抽象的なので、誰が、どの対象に、何をして、何が起きるべきかを書いて、実行できる形にする。良いテストケースには少なくとも前提、操作、期待結果がある。さらにテストデータと確認方法を添えると、別の人が読んでも再現できる。テストコードを書く前にテストケースで合意できると、何を確認するかをチームでそろえられる。
• 具体例：「担当外メンターが担当外受講者のstatusを変更すると403になる」というケースなら、前提（担当メンターと担当外メンターがいる）、操作（担当外メンターとして変更する）、期待結果（403になり、DB上のstatusは変わらない）を書く。
• つまずきやすい点：期待結果を「正しく動く」とだけ書くと、何をもって成功とするかが人によってずれる。
• 関連語：テスト戦略（第13章）、境界値（第13章）
• テキスト本文での登場箇所：第13章「テストケースは、前提、操作、期待結果をそろえる」

単体テスト

• 読み：たんたいテスト（unit test／ユニットテスト）
• 一言で言うと：小さな関数やロジックを、外部要素から切り離して速く確認するテスト。
• くわしく：画面全体やDBを動かさなくても確認できる判断は、単体テストに向いている。実行が速く、失敗したときに原因も追いやすい。ただし、実際の画面やAPI接続の問題は見えにくいという限界がある。小さく速い確認なので、入力検証や値変換のような部品を細かく守るのに使う。
• 具体例：支援ステータス機能では、statusの値変換、不正値の判定、API error codeから画面文言への変換などを単体テストで確認する。
• つまずきやすい点：単体テストだけで安心すると、部品同士をつないだときに起きる不具合を見落とす。
• 関連語：APIテスト（第13章）、E2E（第13章）、テストピラミッド（第13章）
• テキスト本文での登場箇所：第13章「テストの種類は、役割で選ぶ」「テストピラミッドは、速さと範囲の配分を考える図である」

APIテスト

• 読み：エーピーアイテスト（API test／API=Application Programming Interface）
• 一言で言うと：HTTP requestを送り、responseや保存結果を確認するテスト。
• くわしく：APIテストは、API契約と実装のずれを見つける役割がある。単体テストより範囲は広いが、画面を動かすE2Eより速く、認可や入力エラーをまとめて確認しやすい。status code、response body、必要ならDB上の値まで見ることで、約束どおりにふるまうかを確かめられる。
• 具体例：支援ステータス機能では、担当メンターが更新できること、担当外メンターが403になること、不正なstatusが422になること、存在しない受講者が404になることをAPIテストで確認する。
• つまずきやすい点：responseのstatus codeだけ見て、DB上の値が本当に変わった（または変わっていない）かを確認し忘れると、見かけだけ成功するテストになる。
• 関連語：単体テスト（第13章）、E2E（第13章）、回帰確認（第8章）
• テキスト本文での登場箇所：第13章「テストの種類は、役割で選ぶ」「テストピラミッドは、速さと範囲の配分を考える図である」

E2E（エンドツーエンド）

• 読み：イーツーイー（end-to-end／略語の正式名称は End-to-End）
• 一言で言うと：利用者に近い操作から、複数の部品をまたいで流れを確認するテスト。
• くわしく：一覧を開く、statusを選ぶ、保存ボタンを押す、保存中表示を見る、成功や失敗を確認する、という一連の流れをまとめて見る。利用者に近い確認ができる反面、実行が遅く、失敗したときの原因が広くなりやすい。NetworkやConsoleも合わせて見ると、画面とAPIの接続まで説明できる。すべてをE2Eだけで確認すると遅く壊れやすくなるので、代表的な流れに絞って使う。
• 具体例：支援ステータス機能では、メンターが一覧を開いて要支援に変更し、保存成功が表示されるという代表フローを、必要ならE2Eで確認する。
• つまずきやすい点：細かいケースまで全部E2Eにすると、変更のたびに時間がかかり、調査も難しくなる（テストピラミッドの考え方に反する）。
• 関連語：単体テスト（第13章）、APIテスト（第13章）、テストピラミッド（第13章）
• テキスト本文での登場箇所：第13章「テストの種類は、役割で選ぶ」「テストピラミッドは、速さと範囲の配分を考える図である」

統合テスト

• 読み：とうごうテスト（integration test）
• 一言で言うと：複数の部品を組み合わせて、つないだときの動きを確認するテスト。
• くわしく：単体テストが部品を切り離して見るのに対し、統合テストは部品同士の接続を確認する。テストピラミッドでは、速くて狭い単体テストと、遅くて広いE2Eの中間に位置する。部品単体では正しくても、つなぐと食い違うことがあるため、その境目を守るのに使う。範囲が広がるほど実行は遅く、失敗原因も追いにくくなる。
• 具体例：支援ステータス機能では、handlerからuse case、repositoryを経てDBへ書き込むまでをまとめて動かし、PATCH更新が保存まで通るかを確認する形が統合テストにあたる。
• つまずきやすい点：単体・統合・E2Eの線引きは現場やツールで揺れる。名前の区別より、速さ・範囲・信頼性の違いを意識するほうが役に立つ。
• 関連語：単体テスト（第13章）、E2E（第13章）、テストピラミッド（第13章）
• テキスト本文での登場箇所：第13章「テストピラミッドは、速さと範囲の配分を考える図である」

テストピラミッド

• 読み：テストピラミッド（test pyramid）
• 一言で言うと：速さ・範囲・信頼性の違うテストを組み合わせる考え方。
• くわしく：単体テスト、統合テスト、E2Eテストを上下に並べた有名な図である。下にあるほど小さく速く原因を追いやすく、上にいくほど利用者に近いが遅く失敗原因が広い。図の形を暗記しても良いテストは書けない。大切なのは、同じ機能をリスクごとに違う高さから確認することである。どれか一種類が正しいのではなく、配分を考えることが目的である。
• 具体例：支援ステータス機能では、statusの許可値判定は単体テスト、PATCH APIの認可と入力エラーはAPIテスト、保存中表示やキーボード操作は画面確認、代表的な更新フローは必要ならE2E、と高さを分ける。
• つまずきやすい点：上（E2E）に偏ると遅く壊れやすくなり、下に偏ると画面やAPI接続の問題を見落とす。
• 関連語：単体テスト（第13章）、APIテスト（第13章）、E2E（第13章）、統合テスト（第13章）
• テキスト本文での登場箇所：第13章「テストピラミッドは、速さと範囲の配分を考える図である」

TDD（テスト駆動開発）

• 読み：ティーディーディー（test-driven development／略語の正式名称は Test-Driven Development、日本語ではテスト駆動開発）
• 一言で言うと：小さな期待を先にテストへ書いてから実装する進め方。
• くわしく：TDDの基本は Red、Green、Refactor である。Redでは期待するふるまいをテストに書き、まず失敗を確認する。Greenではそのテストを通す最小限の実装を書く。Refactorではふるまいを変えずに名前、重複、構造を整える。Redを飛ばすと、そのテストが本当に期待した失敗を検出できるか分からない。小さなロジックやバグ修正の再現テストに向いており、すべての設計をテストだけで進める高度な手法として身構える必要はない。
• 具体例：支援ステータス機能では、不正なstatusを拒否する isSupportStatus 関数を題材に、「needs_support は有効」「urgent は拒否」という期待を先にテストへ書いてから実装する。
• つまずきやすい点：失敗を確認しないままテストを書くと、最初から通ってしまい、実装が正しいのかテストが何も見ていないのか区別できない。
• 関連語：red-green-refactor（第13章）、テストケース（第13章）、リファクタリング（第8章）
• テキスト本文での登場箇所：第13章「TDDは、小さな期待を先に言葉にする技法である」

red-green-refactor

• 読み：レッド・グリーン・リファクタ（red-green-refactor）
• 一言で言うと：失敗→最小実装→整理、という TDD の3ステップの回し方。
• くわしく：Red は「期待を書いて失敗させる」、Green は「最小限の実装で通す」、Refactor は「ふるまいを変えずに整える」という順番である。この順番を短く何度も回すことで、確認できる範囲を少しずつ増やせる。Red を必ず先に置くのは、テストが本物の失敗を検出できることを保証するためである。Green では正しさより「まず通す」を優先し、Refactor で構造を良くする。
• 具体例：支援ステータス機能では、Red で「urgent を拒否する」テストを失敗させ、Green で許可値の配列に含まれるか判定し、Refactor で配列名を意味の分かる allowedSupportStatuses に整え、API側と画面側で同じ定義を使えるか確認する。
• つまずきやすい点：Refactor を省くと重複や分かりにくい名前が残り、Red を省くとテストが何も検出していない可能性に気づけない。
• 関連語：TDD（第13章）、リファクタリング（第8章）、回帰確認（第8章）
• テキスト本文での登場箇所：第13章「TDDは、小さな期待を先に言葉にする技法である」

境界値

• 読み：きょうかいち（boundary value）
• 一言で言うと：許される値と拒否される値の境目にある入力。
• くわしく：実務で問題になりやすいのは、うまくいく正常系より境界と失敗である。境界値テストは、ちょうど境目の値で正しく許可・拒否されるかを確認する。空文字、null、大小文字違い、余分な空白、上限ちょうど、上限超過などが典型である。境界を先に並べると、実装の条件分岐が自然になり、文言やerror codeも設計とずれにくくなる。
• 具体例：支援ステータス機能では、許可値は none/needs_support/in_progress/resolved なので、空文字や urgent、大文字混じりの値をどう扱うか、支援メモが0文字・上限ちょうど・上限超過のときどうなるかを確認する。
• つまずきやすい点：正常な値だけテストして安心すると、境目の1つ外（上限+1など）で起きる不具合を見逃す。
• 関連語：テストケース（第13章）、単体テスト（第13章）
• テキスト本文での登場箇所：第13章「正常系だけでなく、境界と失敗を先に見る」

カバレッジ

• 読み：カバレッジ（coverage／test coverage、code coverage）
• 一言で言うと：テスト実行時にコードのどれだけが通ったかを示す指標。
• くわしく：カバレッジは実行された行や分岐の割合を示す。テストが届いていない場所を見つける手がかりにはなるが、期待したふるまいを確認できているかまでは保証しない。行を通っているだけで、その行が正しく動くことを検証していないテストもありうる。だから、カバレッジを目標そのものにすると、数字を上げるだけの意味の薄いテストが増える。
• 具体例：支援ステータス機能で、更新処理を全行通すテストがあってもカバレッジは上がるが、担当外メンターを拒否できているかをアサーションしていなければ、肝心のふるまいは守れていない。
• つまずきやすい点：「カバレッジ100%＝バグがない」ではない。実行されたことと、期待どおりかは別である。
• 関連語：テスト戦略（第13章）、テストケース（第13章）
• テキスト本文での登場箇所：第13章「テスト戦略は、先にリスクを選ぶ作業である」「テストと品質で起きやすい誤解」

fixture

• 読み：フィクスチャ（fixture）
• 一言で言うと：テストで使う前提データを、再利用しやすく用意する仕組み。
• くわしく：多くのテストで共通して必要になる前提データ（ユーザーや担当関係など）を、毎回手で書かずにまとめて用意できる。準備の手間が減り、テスト本体が読みやすくなる。ただし前提を隠しすぎると、テストを読んだ人が何を確認しているのか分からなくなる。短さよりも、前提が読めることを優先する。
• 具体例：支援ステータス機能では、assignedMentor（担当メンター）と assignedLearner（担当受講者）の担当関係を fixture として用意し、複数のAPIテストで使い回す。
• つまずきやすい点：fixture に前提を詰め込みすぎると、テスト本体だけ読んでも「誰がどう関係しているか」が見えなくなる。
• 関連語：factory（第13章）、テストケース（第13章）
• テキスト本文での登場箇所：第13章「テストデータは、前提を隠しすぎない」

factory

• 読み：ファクトリ（factory）
• 一言で言うと：テストデータを必要な条件に合わせて作る仕組み。
• くわしく：固定の前提を用意する fixture に対し、factory は「担当外のメンター」「statusが要支援の受講者」のように、条件を指定してデータを生成する。テストごとに少しずつ違うデータが要るときに便利である。ただし、生成のロジックが複雑になると、テストが何の前提で動いているか読みにくくなる。役割が分かる名前を付けて、前提が読めるようにする。
• 具体例：支援ステータス機能では、unassignedLearner（担当外受講者）や、statusだけ違う受講者を factory で作り分け、認可や絞り込みのテストに使う。
• つまずきやすい点：factory に渡す引数が増えすぎると、テストの前提が引数の山に埋もれて読めなくなる。
• 関連語：fixture（第13章）、テストケース（第13章）
• テキスト本文での登場箇所：第13章「テストデータは、前提を隠しすぎない」

mock（モック）

• 読み：モック（mock）
• 一言で言うと：代替部品が「どう呼ばれたか」を確認するためのテスト用部品。
• くわしく：mock は本物の外部部品の代わりに置き、期待された使われ方をしたかを検証する用途で使われることが多い。たとえば、ある処理が1回だけ呼ばれたかを確認する。時刻、メール送信、外部API、重い処理などは本物を毎回動かすと不安定なので、代替に置く。ただし置き換えすぎると、実際の接続の問題を見落とす。何を mock にし、何を本物で確認したかを記録する必要がある。
• 具体例：支援ステータス機能では、保存成功時に通知処理が1回呼ばれたかを mock で確認する、といった使い方ができる。
• つまずきやすい点：mock と stub は混同されやすい。mock は「呼ばれ方の検証」、stub は「応答を返すだけ」と役割で分けると整理しやすい。
• 関連語：stub（第13章）、テストダブル（第13章）、単体テスト（第13章）
• テキスト本文での登場箇所：第13章「mockとstubは、何を置き換えたかを書く」

stub（スタブ）

• 読み：スタブ（stub）
• 一言で言うと：決まった応答を返すだけのテスト用の代替部品。
• くわしく：stub は、本物の外部部品の代わりに、あらかじめ決めた応答を返す。呼ばれ方を検証する mock と違い、stub は「こう返ってきたとき、こちらの処理はどうなるか」を確かめるために使う。外部サービスやランダムな値、重い処理を安定させたいときに置く。置き換えた範囲が広いほど、実物で初めて分かる不具合が残るので、何を stub にしたかを記録する。
• 具体例：支援ステータス機能では、外部通知サービスの代わりに「成功した」という応答だけを返す stub を置き、保存後の処理の流れを確認する。
• つまずきやすい点：stub で固定した応答が現実とずれていると、テストは通っても本番で壊れる。
• 関連語：mock（第13章）、テストダブル（第13章）、APIテスト（第13章）
• テキスト本文での登場箇所：第13章「mockとstubは、何を置き換えたかを書く」

テストダブル

• 読み：テストダブル（test double）
• 一言で言うと：本物の部品の代わりにテストで使う代替部品の総称。
• くわしく：mock や stub は、より大きな「テストダブル」という考え方の一種である（double は映画の「代役」に由来する）。本物を毎回動かすと不安定・遅い・外部に影響する場合に、代わりの部品を置く。便利だが、置き換えすぎると実際の接続・認可・DB保存の問題を見落とす。どこまで代役にし、どこは本物で確認したかを切り分けて記録することが重要である。
• 具体例：支援ステータス機能では、外部通知サービスをテストダブルに置き換える一方、PATCH APIの認可とDB保存は本物を動かして確認する、という分担を記録する。
• つまずきやすい点：mock・stub・fake など細かい呼び分けは流派で揺れる。まずは「代役を置いた範囲と、本物で確認した範囲を分けて書く」ことが大切である。
• 関連語：mock（第13章）、stub（第13章）、単体テスト（第13章）
• テキスト本文での登場箇所：第13章「mockとstubは、何を置き換えたかを書く」

アサーション

• 読み：アサーション（assertion／日本語では表明・検証）
• 一言で言うと：テストの中で「結果がこうあるべき」と期待を突き合わせる宣言。
• くわしく：テストは操作するだけでは成立しない。実行した結果が期待どおりかをアサーションで確認して、初めて成功・失敗が決まる。期待結果（status、DB上の値、error code など）を明示することで、何を守っているかがコード上に残る。アサーションが弱い（例: エラーが出ないことだけ確認する）と、コードを通しても肝心のふるまいを検証できていないテストになる。
• 具体例：支援ステータス機能の担当外メンターのテストでは、「response status が403であること」「DB上のstatusが変わっていないこと」「権限エラーのcodeが返ること」をアサーションする。
• つまずきやすい点：操作だけ書いてアサーションを忘れると、テストは「通る」がカバレッジを稼ぐだけで何も守らない。
• 関連語：テストケース（第13章）、カバレッジ（第13章）
• テキスト本文での登場箇所：第13章「テストケースは、前提、操作、期待結果をそろえる」

テスト名

• 読み：テストめい（test name／test naming）
• 一言で言うと：そのテストが守るふるまいを、失敗時の説明として読める名前。
• くわしく：テスト名は将来の読者への説明である。testUpdate や shouldWork のような名前では、何を守っているか分からず、失敗時に何を調べればよいかも分からない。前提・操作・期待結果のうち、読者が理解するのに必要な情報を入れる。多少長くても、ふるまいが読める名前のほうがよい。実装の関数名をそのままテスト名にしない。
• 具体例：支援ステータス機能では「担当外メンターが更新しようとすると403になり、保存値は変わらない」のように、ふるまいが読めるテスト名にする。
• つまずきやすい点：長さを恐れて意味を削ると、失敗ログを見ても何が壊れたか分からなくなる。
• 関連語：テストケース（第13章）、アサーション（第13章）
• テキスト本文での登場箇所：第13章「テスト名は、失敗したときの説明になる」

flaky test（フレイキーテスト）

• 読み：フレイキーテスト（flaky test）
• 一言で言うと：同じコードでも、実行するたびに成功したり失敗したりする不安定なテスト。
• くわしく：時刻、ランダムな値、外部API、ネットワーク、処理の順序や待ち時間などに依存すると、結果が安定しないテストになりやすい。flaky なテストは「失敗しても無視してよい」という空気を生み、本当のバグを見逃す原因になる。本文では、時刻・メール送信・外部APIなどを本物で毎回動かすと不安定になるため代替部品（mock/stub）を使う、と説明されており、これは flaky を避ける工夫でもある。
• 具体例：支援ステータス機能で、保存処理が外部通知サービスへ実通信していると、その日のネットワーク状況でテストが落ちたり通ったりする。stub に置き換えると安定する。
• つまずきやすい点：flaky を「再実行すれば通る」で済ませると、本物の不具合が混ざっていても気づけない。
• 関連語：stub（第13章）、mock（第13章）、E2E（第13章）
• テキスト本文での登場箇所：第13章「mockとstubは、何を置き換えたかを書く」

再現テスト

• 読み：さいげんテスト（regression test／bug reproduction test）
• 一言で言うと：起きたバグを先に再現させ、直したら通るようにして残すテスト。
• くわしく：バグ修正では、まず「そのバグが起きること」を示すテストを書く（このとき失敗する）。修正後にそのテストが通れば、確かに直ったと分かる。一度起きたバグは似た変更で戻ることがあるため、再現テストを残すと「このバグは戻さない」という印になる。回帰確認の一部として効果が高く、TDDのRed→Greenとも相性がよい。
• 具体例：支援ステータス機能で「担当外メンターが特定条件で更新できてしまう」バグが見つかったら、その条件を再現する失敗テストを書き、修正後に通ることを確認して残す。
• つまずきやすい点：修正だけして再現テストを残さないと、同じバグが将来の変更で静かに復活する。
• 関連語：回帰確認（第8章）、TDD（第13章）、テストケース（第13章）
• テキスト本文での登場箇所：第13章「TDDが向く場面と向かない場面を分ける」「回帰確認は、直した場所以外を見るためにある」

内部品質

• 読み：ないぶひんしつ（internal quality）
• 一言で言うと：利用者からは見えにくいが、未来の変更速度に効くコードの質。
• くわしく：内部品質は、読みやすさ、変更しやすさ、テストしやすさ、レビューしやすさに関わる。名前が曖昧なコードは読むたびに推測が要り、責務が混ざった関数は少しの変更で広く影響し、重複したロジックは直し漏れを生む。これらは好みの問題ではなく、プロダクトを継続して直すための実務上の品質である。本文では naming、responsibility、duplication、complexity、testability の観点で見る。
• 具体例：支援ステータス機能で、handlerに入力検証・認可・DB更新・response作成が混ざっていると、入力検証だけを直したいときも全体を読む必要があり、内部品質が低い状態である。
• つまずきやすい点：利用者に見えないため後回しにされやすいが、放置すると次の変更が遅く・危険になる。
• 関連語：技術的負債（第13章）、リファクタリング（第8章）、testability（第13章）
• テキスト本文での登場箇所：第13章「内部品質は、未来の変更速度に効く」

技術的負債

• 読み：ぎじゅつてきふさい（technical debt）
• 一言で言うと：後で直す必要が出る、設計・実装上の借り。
• くわしく：負債という言葉は悪いコードを責めるためのものではない。時間の制約や優先度の都合で、あえて残すこともある。ただし意図的に残すなら、何を残したか、なぜ今回直さないか、どんな影響があるか、いつ直すかを記録する。書かずに放置すると、後の読者には意図した判断なのか見落としなのか区別できない。記録すれば次の改善候補になる。
• 具体例：支援ステータス機能では「E2Eは未整備で代表フローは手動確認に残す」「支援メモの文字数制限はAPI側だけで画面側の事前表示は未実装」などを技術的負債として記録する。
• つまずきやすい点：負債を隠すと、後から見た人が「わざと残したのか、忘れたのか」を判断できない。記録してこそ扱いやすくなる。
• 関連語：内部品質（第13章）、セルフレビュー（第13章）
• テキスト本文での登場箇所：第13章「技術的負債は、残すなら記録する」

testability（テスト容易性）

• 読み：テスタビリティ（testability／日本語ではテスト容易性）
• 一言で言うと：コードを小さく確認できる単位に分けられているか、という性質。
• くわしく：testability が低いと、変更のたびに手動確認へ依存しやすくなる。逆に、責務が分かれていてテストしづらい依存を切り出せていれば、単体テストやAPIテストで素早く確認できる。内部品質を見る観点の一つで、リファクタリングはテスト容易性を上げる手段にもなる。テストしやすい構造は、結果的に変更しやすい構造でもある。
• 具体例：支援ステータス機能で、status許可値の判定を isSupportStatus のような小さな関数に切り出すと、画面やDBを動かさず単体テストで確認でき、testability が上がる。
• つまずきやすい点：テストしづらいのはテストの書き方の問題だけでなく、設計（責務の混在や依存の絡まり）の問題であることが多い。
• 関連語：内部品質（第13章）、単体テスト（第13章）、リファクタリング（第8章）
• テキスト本文での登場箇所：第13章「内部品質は、未来の変更速度に効く」

セルフレビュー

• 読み：セルフレビュー（self review）
• 一言で言うと：PRに出す前に、自分の変更を自分で見直す確認。
• くわしく：セルフレビューは、差分を読み直し、実行したテスト、手動確認、未確認事項、コード品質上の懸念、残した負債を整理する作業である。大切なのは、実行していない確認を「確認済み」と書かないことである。確認済みの範囲と未確認の範囲を事実として分けると、レビュアーは次に何を見るべきかを判断できる。自分を守るためだけでなく、チームが変更を受け入れる判断材料になる。
• 具体例：支援ステータス機能では「APIテストは実行済み、保存失敗表示は手動確認済み、キーボード操作は未確認」のように、確認状況を分けて書く。
• つまずきやすい点：「すべて確認済み」と言い切るより、未確認を正直に書くほうがレビューで信頼される。
• 関連語：技術的負債（第13章）、回帰確認（第8章）
• テキスト本文での登場箇所：第13章「quality-reviewは、確認済みの範囲を説明する文書である」

リファクタリング

• → 第8章（外から見えるふるまいを変えず、内部構造を整理する変更）。第13章では、テストがふるまい維持の支えになる点が重要で、仕様変更と混ぜずに「変えないふるまい」を先に書いてから整理する。

回帰確認

• → 第8章（変更で以前のふるまいが壊れていないかを見る確認）。第13章では、直した場所以外（一覧表示、絞り込み、権限拒否、画面のエラー表示など）まで見ること、バグ修正では再現テストを残すことが、テスト文脈での要点になる。