知識マップ: ユニットテストと結合テストの境界をどう引くか

記事「ユニットテストと結合テストの境界をどう引くか」の主張を、概念と関係(エッジ)に分解した知識グラフの全体です。各関係には根拠・確認日・確度が付いています。

ユニットテストと結合テストの境界を、判断のテストか接続のテストかという軸で整理する記事です。金額計算や状態遷移のような分岐の総当たりはユニットテストへ寄せ、フォーマット・配線・環境・時間という4つの境界はin-memoryのfakeでは意味が落ちるため結合テストへ置くべきだとします。stub・mock・fakeというテストダブルの違いを整理したうえで、mockが増えすぎる兆候は配線をユニットテストへ押し込んでいる合図であり、コア層をユニットテストで厚く、境界層を狭い結合テストで、全体層を少数のスモーク/E2Eで構成する3層構成を実務での落としどころとして示します。

flowchart LR
    accTitle: ユニットテストと結合テストの境界の知識マップ
    accDescr: ユニットテストが判断のテストで結合テストが接続のテストであること、フォーマット・配線・環境・時間という4つの境界が結合テスト側に置かれるべきこと、stub・mock・fakeの違いとmock過多が配線の混入を示す兆候であること、コア層・境界層・全体層からなる3層のテスト構成の関係を示す図
    unit_test["ユニットテスト"]
    integration_test["結合テスト"]
    test_stub["スタブ"]
    test_mock["モック"]
    test_fake["フェイク"]
    format_boundary["フォーマットの境界"]
    wiring_boundary["配線の境界"]
    environment_boundary["環境の境界"]
    time_boundary["時間の境界"]
    branching_coverage["分岐の総当たり"]
    bitness_match_requirement["bitness一致要件"]
    com_apartment_model["COMアパートメントモデル(STA/MTA)"]
    mock_overuse_smell["mockが増えすぎる兆候"]
    three_layer_test_structure["3層のテスト構成"]
    e2e_test["E2Eテスト"]
    unit_test -.->|"利用する"| test_stub
    unit_test -.->|"利用する"| test_mock
    unit_test -.->|"利用する"| test_fake
    integration_test -->|"推奨される対応"| format_boundary
    integration_test -->|"推奨される対応"| wiring_boundary
    integration_test -->|"推奨される対応"| environment_boundary
    integration_test -->|"推奨される対応"| time_boundary
    unit_test -->|"推奨される対応"| branching_coverage
    environment_boundary -.->|"前提とする"| bitness_match_requirement
    environment_boundary -.->|"前提とする"| com_apartment_model
    test_mock -.->|"原因になり得る"| mock_overuse_smell
    unit_test -->|"用いるのは非推奨"| wiring_boundary
    three_layer_test_structure -->|"前提とする"| unit_test
    three_layer_test_structure -->|"前提とする"| integration_test
    three_layer_test_structure -->|"前提とする"| e2e_test
    integration_test -->|"用いるのは非推奨"| branching_coverage
    test_fake -->|"用いるのは非推奨"| environment_boundary
    test_fake -->|"用いるのは非推奨"| format_boundary

概念間の関係(全18件)

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

• ユニットテストはスタブを利用します。テスト対象を協力オブジェクトから切り離す必要がある場合、入力条件を固定するためにコントロール可能な代役であるstubを使う。純粋関数や値オブジェクトのユニットテストには代役自体が不要で、stub・mock・fakeは目的に応じて使い分ける選択肢である / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• ユニットテストはモックを利用します。呼び出しが行われたこと自体をAssertの対象にしたい場合に、その検証のためmockを使う。純粋関数や値オブジェクトのユニットテストには代役自体が不要で、stub・mock・fakeは目的に応じて使い分ける選択肢である / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• ユニットテストはフェイクを利用します。軽量な代替実装で足りる場合にfakeを使う(stubやmockの総称として使われることもある)。純粋関数や値オブジェクトのユニットテストには代役自体が不要で、stub・mock・fakeは目的に応じて使い分ける選択肢である / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• 結合テストはフォーマットの境界に対する本記事の推奨です。JSON/CSVのシリアライズやDBのmappingなど、フォーマットの境界を確かめる主力として結合テストが本記事の推奨である / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 結合テストは配線の境界に対する本記事の推奨です。DI登録、ルーティング、モデルバインディングなど配線の境界を確かめる主力として結合テストが本記事の推奨である / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 結合テストは環境の境界に対する本記事の推奨です。ファイル権限、COM登録、32bit/64bit、STA/MTAなど環境の境界を確かめる主力として結合テストが本記事の推奨である / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 結合テストは時間の境界に対する本記事の推奨です。実際にtimeoutが効くか、cancellationが伝播するかなど時間の境界を確かめる主力として結合テストが本記事の推奨である / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• ユニットテストは分岐の総当たりに対する本記事の推奨です。クーポンあり/なし、在庫あり/なしのように分岐条件が増える入力パターンの総当たりには、ユニットテストが本記事の推奨である / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 環境の境界はbitness一致要件を前提とします。環境の境界には、32bit/64bitのビット数一致という制約の確認が含まれる(ファイル権限やCOM登録など他の懸念も環境の境界に含まれ、bitnessはそのうちの1つの例に過ぎない) / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• 環境の境界はCOMアパートメントモデル(STA/MTA)を前提とします。環境の境界には、STA/MTAのようなCOMのアパートメントモデルの確認が含まれる(COMやActiveXを含む構成の場合の例であり、環境の境界すべてにCOMアパートメントモデルが関わるわけではない) / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• モックはmockが増えすぎる兆候の原因になることがあります。mockによる呼び出し検証をユニットテストに積み重ねすぎると、mockが増えすぎる兆候につながることがある / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• ユニットテストを配線の境界に用いることは推奨されません。DI登録やモデルバインディングなど配線の境界を、mockを積み重ねたユニットテストで確かめようとすることは、本物との接続の証明にならないため推奨されない / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 3層のテスト構成はユニットテストを前提とします。3層のテスト構成のコア層は、業務ルールや状態遷移をユニットテストで厚く持つ / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 3層のテスト構成は結合テストを前提とします。3層のテスト構成の境界層は、DBやファイル、serializer、DIなどに狭い結合テストを置く / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 3層のテスト構成はE2Eテストを前提とします。3層のテスト構成の全体層は、起動確認や主要フローを少数のスモーク/E2Eで押さえる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 結合テストを分岐の総当たりに用いることは推奨されません。結合テストで入力パターンを総当たりすることは重くなりすぎるため推奨されず、代表的なシナリオへ絞ることが勧められている / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• フェイクを環境の境界に用いることは推奨されません。in-memoryのfakeではファイル権限やCOM登録、32bit/64bitなど環境の境界の意味がかなり落ちるため、fakeをこの確認に用いることは推奨されない / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• フェイクをフォーマットの境界に用いることは推奨されません。wire formatのズレはfakeでは見つけにくいため、fakeをフォーマットの境界の確認に用いることは推奨されない / 確度: 確立した関係 / 確認日: 2026-08-01 出典

主要概念の定義

ユニットテスト

分離された1責務の正しさを、外部資源を切り離して確かめるテストの層のこと。

結合テスト

複数コンポーネントの接続と、インフラやフレームワークを含む挙動を確かめるテストの層のこと。

環境の境界

ファイル権限、COM登録、32bit/64bit、STA/MTAなど、OSや実行環境の実挙動に関わる境界のこと。

モック

テストの合否を左右するAssert操作の対象になる、呼ばれ方そのものを検証する代役のこと。

3層のテスト構成

コア層をユニットテストで厚く、境界層を狭い結合テストで、全体層を少数のスモーク/E2Eで構成するテストの配置構成のこと。

フェイク

スタブやモックを指す総称、または本物と同じ振る舞いを軽い実装で置き換えたもののこと。

機械可読データ

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

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