単体テストは大事だと頭では分かっていても、
**「あー、めんどくさい……」**という感覚は、多くのエンジニアが経験しています。
- 実装より書くのがしんどい
- モック作るのがだるい
- そもそもテストの価値が分からない瞬間がある
- レガシーコードだと地獄
- テストのためのテストみたいになる
……などなど。
この記事では、この 「めんどくさい」の正体を心理モデル＝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モデルで“気持ちの正体”を理解すると楽になります。