単体テストは大事だと頭では分かっていても、
**「あー、めんどくさい……」**という感覚は、多くのエンジニアが経験しています。

実装より書くのがしんどい
モック作るのがだるい
そもそもテストの価値が分からない瞬間がある
レガシーコードだと地獄
テストのためのテストみたいになる

……などなど。

この記事では、この 「めんどくさい」の正体を心理モデル＝ABCモデルで分解し、
さらに Python のコード付きで“テストを楽にする”アプローチまで紹介します。

✅ ABCモデルとは？

本記事では次のシンプル版を使います：

観点	意味
A：Authenticity（生・自然）	本能的反応・体感的な負荷・直感的しんどさ
B：Aesthetic（基準・評価）	正しさ・べき論・評価圧・責務の重さ
C：Meta（俯瞰・構造）	俯瞰・システム設計・全体像の把握

これを「単体テスト」に当てはめると、
“なぜしんどいのか”を3層構造で理解できるようになります。

✅ 1. A（Authenticity）：単体テストは“体感的にめんどくさい”

単体テストの「めんどくさい」は、まず A＝生の反応 に強く出ます。

✅ A-1. コードを書くより“作業感”が強い

実装は楽しいけど、テストは作業っぽい。

手が動きにくい
書き始めに抵抗がある
実装の勢いが削がれる

→ A の「本能的なしんどさ」「身体的だるさ」に該当

✅ A-2. テストコードのほうが冗長になりがち

Arrange/Act/Assert が面倒
モックの設定が多い
目的の割に手数が多い

→ “労力＞成果” に見えると A が急激に下がる

✅ A-3. 書いてもすぐに快感が得られない

実装は「動いた！」で dopamine が出る。
テストは即時の報酬が弱い。

✅ 2. B（Aesthetic）：テストには“評価圧と基準の厳しさ”がある

次に、単体テストは “B＝べき論・基準意識の世界” になりがちです。

✅ B-1. 正しさの基準が多い（＝美意識の圧）

テストは独立であるべき
副作用を避けるべき
境界値まで網羅すべき
可読性高くあるべき
セマンティクスが明確であるべき

「べき」が多い＝B（評価圧） が強い。

✅ B-2. テストを書くと設計の矛盾が露呈する

DI 化が必要
責務分離が甘い
メソッドが肥大化している
結局リファクタが必要になる

→ 「理想のコード」と「現実」にギャップが生じ、B が揺れる（ΔB）

✅ B-3. 書かなければ“悪”のような空気

チーム文化により、

カバレッジ
PR時のレビュー
テスト未整備の指摘

などの評価圧が強いケースもある。

✅ 3. C（Meta）：単体テストは“俯瞰的に正義だが、個人にとって遠い”

俯瞰視点で見れば、

テストがあれば保守性が上がる
バグを早期に防げる
リファクタ時の安全性が増す
組織としての品質が上がる

などの 全体最適（C） が実現される。

しかし……

✅ C-1. 「未来の誰かのため」がモチベになりにくい

今すぐ楽になるより、未来が楽
エンジニアの脳は“短期報酬”に弱い

→ C（俯瞰）は理解できる
→ だが A がしんどく、B がうるさいため葛藤が起こる

✅ C-2. テスト戦略を俯瞰するのが難しい

単体？結合？E2E？
どこまで書けば十分？
モジュール境界は？

→ C の“メタ構造づくり”が負担になりうる

✅ C-3. プロダクト全体の要求と自分の作業負荷が噛み合わない

スケジュールがタイト
仕様が固まっていない
テストより実装を急ぎたい局面

プロジェクト俯瞰（C）と開発者のA/Bがズレてストレスになる。

✅ ✅ まとめ：単体テストがめんどくさい理由（ABCモデル）

観点	めんどくささの要因
A（生）	作業感が強い / 即時報酬が弱い / モックが多い
B（評価）	“べき論”が多い / 設計の粗が露呈する / レビュー圧
C（俯瞰）	全体最適は理解できるが、自分の負荷とズレる

→ 単体テストは A／B／C の全てにストレスがかかる“フルコンボ領域”。
だから誰でもめんどくさくて当然。

✅ ではどうする？ → A/B/C のそれぞれを軽くすれば楽になる

A対策（作業しやすくする）
→ テストコードのテンプレ化
→ モックを減らした設計
→ pytest のように“軽く書ける環境”を導入
B対策（評価圧を下げる）
→ 完璧なテストを目指さない
→ カバレッジ至上主義を避ける
→ 小さいテストから始める
C対策（俯瞰負荷を軽くする）
→ テストの目的を「未来の安心コスト削減」と割り切る
→ “守りの投資”としてのフレームワークを決める

✅ Python で“めんどくささを軽減する単体テスト”例

ここでは pytest を使った「最小労力のテスト」を見せます。

✅ 例）計算関数のテスト（最小コスト版）

productionコード `calc.py`

def add(a, b):
    return a + b

def divide(a, b):
    if b == 0:
        raise ValueError("division by zero")
    return a / b

単体テスト `test_calc.py`

import pytest
from calc import add, divide

def test_add():
    assert add(2, 3) == 5

def test_divide():
    assert divide(10, 2) == 5

def test_divide_by_zero():
    with pytest.raises(ValueError):
        divide(10, 0)

✅ 書きやすい理由

Arrange/Act/Assert の厳密な三分割が不要（A対策）
pytest は自然なコードで書ける（A対策）
エラーの期待も自然に書ける（B対策）
テスト体系を pytest が用意してくれる（C対策）

✅ さらに“テストを楽にする”テク：パラメトライズ

import pytest
from calc import add

@pytest.mark.parametrize("a, b, expected", [
    (1, 2, 3),
    (5, 5, 10),
    (-3, 5, 2)
])
def test_add_cases(a, b, expected):
    assert add(a, b) == expected

何ケースも書くストレスが一気に減る（A減）
テストの網羅性が上がる（B安定）
テスト体系の俯瞰性が上がる（C向上）

✅ 結論：単体テストは“めんどくさい”が、ABCモデルで分ければ攻略できる

**A（生）**では「作業的だるさ」が、
**B（評価）**では「べき論・責務」が、
**C（俯瞰）**では「全体最適とのギャップ」が、

それぞれ負荷として積み重なるため、
単体テストは本質的にめんどくさい。

しかし逆に言えば、
A/B/C のどこを軽くすれば良いかが明確になる。

A：書き味を軽くする（pytest・テンプレ）
B：評価圧を避ける（完璧を求めない）
C：体系を固定する（フレームワーク化）

単体テストがしんどい人ほど、
ABCモデルで“気持ちの正体”を理解すると楽になります。