知識マップ: テストのないレガシー業務アプリに安全に手を入れる ── 特性化テストとリファクタリングの実践

記事「テストのないレガシー業務アプリに安全に手を入れる ── 特性化テストとリファクタリングの実践」の主張を、概念と関係(エッジ)に分解した知識グラフの全体です。各関係には根拠・確認日・確度が付いています。

この記事は、自動テストのないレガシーコードに安全に手を入れるための手順を扱います。まず特性化テストで現在の挙動を固定し、出力の単位が大きい場合はゴールデンマスター法で期待値ファイルとの差分比較を行います。UIに直書きされたロジックには、メソッド抽出とインターフェース差し込みで継ぎ目(seam)を作り、必要ならInternalsVisibleTo属性でinternalメンバーをテストから見えるようにします。リファクタリングは差分ゼロ、機能追加は意図した差分だけが合格条件であるため同じコミットに混ぜてはならず、期待値の更新は差分レビューを経てから行うことで、退行を見逃すリスクを防ぎます。

flowchart LR
    accTitle: 特性化テストとレガシーコード改修の知識マップ
    accDescr: 特性化テストとゴールデンマスター法でレガシーコードの現在の挙動を固定し、継ぎ目(seam)を作ってリファクタリングと機能追加を安全に分離する関係を示す図
    characterization_test["特性化テスト"]
    legacy_code["レガシーコード"]
    method_extraction_refactoring["メソッド抽出"]
    refactoring["リファクタリング"]
    golden_master_testing["ゴールデンマスター法"]
    regression_risk["退行リスク"]
    golden_master_diff_review["期待値の差分レビュー"]
    mixed_commit_antipattern["リファクタリングと機能追加の混在コミット"]
    seam["継ぎ目(seam)"]
    dependency_injection_seam["インターフェース差し込み"]
    internals_visible_to["InternalsVisibleTo属性"]
    output_normalization["出力の正規化"]
    dotnet_test_command["dotnet testコマンド"]
    vstest_console["vstest.console.exe"]
    characterization_test -->|"より先に行うべき"| method_extraction_refactoring
    characterization_test -->|"より先に行うべき"| refactoring
    golden_master_testing -->|"実装を担う"| characterization_test
    golden_master_testing -->|"推奨される対応"| legacy_code
    legacy_code -.->|"原因になり得る"| regression_risk
    characterization_test -->|"軽減する"| regression_risk
    golden_master_diff_review -->|"軽減する"| regression_risk
    mixed_commit_antipattern -.->|"原因になり得る"| regression_risk
    method_extraction_refactoring -->|"実装を担う"| seam
    dependency_injection_seam -->|"実装を担う"| seam
    seam -.->|"で構成できる"| internals_visible_to
    refactoring -->|"両立しない"| mixed_commit_antipattern
    golden_master_testing -.->|"前提とする"| output_normalization
    regression_risk -.->|"で確認できる"| dotnet_test_command
    regression_risk -.->|"で確認できる"| vstest_console
    characterization_test -->|"推奨される対応"| legacy_code
    seam -->|"推奨される対応"| legacy_code
    dotnet_test_command -.->|"両立しない"| legacy_code
    vstest_console -.->|"推奨される対応"| legacy_code

概念間の関係(全19件)

図と同じ関係を文章でも列挙します。表示している文と機械可読な意味データ(RDFa)は同じ要素に載っています。確度が「確立した関係」のものは直接の関係として、「条件付きの関係」のものは成立条件つきの言明(rdf:Statement)として表現しています。

• 特性化テストはメソッド抽出より先に行うべきです。変更する箇所の周辺だけ現在の挙動を特性化テストで固定してから、継ぎ目を作るための最小限のリファクタリング(メソッド抽出)を行う / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 特性化テストはリファクタリングより先に行うべきです。テスト可能な構造になったら、特性化テストという安全網の内側で本来のリファクタリングや機能追加に着手する / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• ゴールデンマスター法は特性化テストの実装を担います。ゴールデンマスター法は、出力をそのまま期待値ファイルとして保存し差分比較することで特性化テストを実現する具体的な手法である / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• ゴールデンマスター法はレガシーコードに対する本記事の推奨です。出力の単位が大きいレガシーコードには、ゴールデンマスター法が最も費用対効果の高い特性化テストであるというのが本記事の推奨である / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• レガシーコードは退行リスクの原因になることがあります。テストのないレガシーコードでは、変更結果が正しいかを確かめる手段がないため、意図しない挙動変化(退行)に気づけないリスクがある / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• 特性化テストは退行リスクを軽減します。特性化テストは現在の挙動を期待値として固定し、変更のたびに差分比較することで退行リスクを軽減する / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 期待値の差分レビューは退行リスクを軽減します。期待値を更新する前に差分を1行1行目視でレビューすることで、意図しない退行をそのまま正として取り込んでしまう事故のリスクを軽減する(人手のレビューのため見落としが残り得る) / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• リファクタリングと機能追加の混在コミットは退行リスクの原因になることがあります。リファクタリングと機能追加を同じコミットに混ぜると、差分が出たときに意図した変更か退行かを切り分けられなくなる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• メソッド抽出は継ぎ目(seam)の実装を担います。メソッド抽出は、計算部分だけを切り出し外部依存を引数化することで、テストから挙動を観測できる継ぎ目を作る代表的な手段である / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• インターフェース差し込みは継ぎ目(seam)の実装を担います。引数化だけでは済まない規模の依存には、インターフェースで包んで差し替え可能にすることで継ぎ目を作る / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 継ぎ目(seam)はInternalsVisibleTo属性で構成できます。internalのままテストしたい継ぎ目は、本体側にInternalsVisibleTo属性を1行加えることでテストプロジェクトから見えるように構成できる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• リファクタリングはリファクタリングと機能追加の混在コミットと両立しません。差分ゼロが合格条件のリファクタリングと、意図した差分だけが合格条件の機能追加は合格条件が正反対のため、同じコミットに混ぜてはならない / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• ゴールデンマスター法は出力の正規化を前提とします。印字日時やGUIDなど非決定的な値が出力に混ざる場合、比較の前に出力の正規化を挟まないと毎回差分が出てしまう / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• 退行リスクはdotnet testコマンドで確認できます。退行の有無はコミット前にdotnet testを実行し、差分ゼロであることを確認して判断できる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• 退行リスクはvstest.console.exeで確認できます。旧形式のcsprojが混在しdotnet testが動かない場合は、vstest.console.exeでビルド済みテストDLLを直接実行して退行の有無を確認できる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• 特性化テストはレガシーコードに対する本記事の推奨です。仕様書がなくテストもないレガシーコードに安全に手を入れるには、まず特性化テストで現在の挙動を固定することが本記事の推奨である / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 継ぎ目(seam)はレガシーコードに対する本記事の推奨です。UIイベントハンドラー直書きや現在時刻への直接依存のように、テストを差し込めない構造のレガシーコードには継ぎ目を作ることが本記事の推奨である / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• dotnet testコマンドはレガシーコードと両立しません。旧形式(非SDKスタイル)のcsprojが混ざったレガシーなソリューションでは、dotnet testコマンドが期待どおりに動かないことがある / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• vstest.console.exeはレガシーコードに対する本記事の推奨です。dotnet testが期待どおりに動かないレガシーなソリューションでは、vstest.console.exeを使う方法が代替手段として推奨される / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典

主要概念の定義

特性化テスト

正しい挙動ではなく、いまのコードが実際にどう振る舞っているかという「現在の挙動」を記録するテスト。

レガシーコード

Michael Feathersが「単に古いコード」ではなく「テストのないコード」として定義した、変更結果を確かめる手段を欠いたコード。

ゴールデンマスター法

変更対象の出力をそのまま期待値ファイル(ゴールデンマスター)として保存し、以後のコード変更のたびに出力と期待値の差分がゼロであることを確認する特性化テストの具体的な手法。

期待値の差分レビュー

ゴールデンマスターを更新する前に、変更前後の出力差分を目視でレビューし、意図した変更だけが含まれることを確認する運用手順。

リファクタリングと機能追加の混在コミット

挙動を変えない変更(リファクタリング)と挙動を変える変更(機能追加・バグ修正)を同じコミットに混ぜてしまう運用上のアンチパターン。

メソッド抽出

UIイベントハンドラーなどに直書きされたロジックを、外部依存を引数として受け取る別メソッドへ切り出すリファクタリング手法。

インターフェース差し込み

DateTime.Nowやファイルパスの直接参照など、引数化だけでは済まない依存をインターフェースで包み、テスト側で差し替え可能にする手法。

継ぎ目(seam)

Michael Feathersの言う、テストコードから挙動を差し替え・観測できる場所。

リファクタリング

挙動を変えることなく、コードを保守・理解・拡張しやすくするために構造を変更するプロセス。

退行リスク

変更によって意図しない挙動変化(退行)が入り込み、それに気づけないリスク。

dotnet testコマンド

.NET SDKに含まれる標準のテスト実行コマンド。

vstest.console.exe

ビルド済みのテストDLLを直接指定して実行できる、Developer Command Promptから使うコマンドラインツール。

機械可読データ

• JSON-LD / Turtle ── この記事の知識グラフ全体
• 概念一覧 / 語彙(述語)の定義

このページはサイトの知識グラフ(_data/knowledge/)から自動生成されています。誤りの指摘はお問い合わせからお願いします。