第31回：【テストコードのガイドライン その6】【密結合】staticメソッドの呪い ── テスト不能な「固まった心臓」

♨️ ヒマリの悲鳴と「動かない」エディタ

東根温泉支部の廊下に、春ののどかな空気を切り裂くような悲鳴が響き渡った。

「サキ先輩ぃ〜〜！！ 助けてください！ テストが……テストが全然書けないんです！」

声の主は、もちろんヒマリだ。数分前まで「テストの境界線は見えた！」と意気揚々とデスクに向かっていたはずの彼女が、今は頭を抱え、モニターの前で半泣きになっている。

サキ： 「どしたの、ひま？ 温泉の温度設定でも間違えて、のぼせちゃった？✨」

サキが、いつものように軽い足取りでヒマリのデスクにやってくる。

ヒマリ： 「温度どころじゃないですよ！ この『ログインユーザーの権限チェック』のテストを書こうとしたんですけど、モック化しようとしてもエラーが出るし、無理やりテストを流そうとすると、1ケースごとにPCが固まったみたいに重くなるんです……。これ、私のPCが壊れてるんでしょうか？」

ヒマリのモニターには、無機質なスタックトレースの山と、数分間も「Running...」のまま動かないプログレスバーが映し出されていた。

♨️ コードに刻まれた「static」の刻印

サキはヒマリからマウスを借り、問題のプロダクションコードをスクロールさせた。そこには、一見すると非常に「読みやすく」「整然とした」コードが並んでいた。

def publish_article(self, article_id):
    # ログインユーザーを取得
    user = Auth::user() 
    
    # 権限をチェック
    if not Permission::check(user, 'can_publish'):
        raise Exception("権限がありません")
        
    # 日付をフォーマット
    published_at = TimeUtil::format_now()
    
    # ...記事公開処理

サキ： 「あ〜……。これね。これかぁ……。✨」

サキの口調から、いつもの軽やかさが少しだけ消えた。

ヒマリ： 「えっ、何か変ですか？ Auth::user() とか TimeUtil::format() とか、どこからでも呼べて便利だし、コードもスッキリしてていいなって思ってたんですけど……。」

サキ： 「うん、書くのは楽だよね。でもね、ひま。これ、テストの神様から見たら『絶対お断り』なコードなんだよ。✨ このコードには、テストの自由を奪う呪いが至る所に刻まれてるんだ。」

♨️ 密結合の正体 ── プロセス分離の弊害

ルル： 「（背後から現れ、指で大きくバツ印を作って断言する）……当然です。staticは 『密結合』 の権化ですッ！😤」

突然のルルの登場に、ヒマリは背筋を正す。

ヒマリ： 「密結合……。でも、ただの便利ツールを呼んでいるだけじゃないですか。」

ルル： 「それが大きな間違いですッ！ staticメソッドがなぜ単体テストに不都合なのか、その理由は大きく分けて二つあります。😤」

① 差し替え不能な「壁」

ルル： 「テストとは、対象のコードを外部から切り離し、依存している部品を『身代わり（モック）』に差し替えて実験する行為です。しかし、Auth::user() のようにクラス名に直接紐づいたメソッドは、外部から差し替える隙間がありません。本物の認証処理、本物のDB接続を強制的に引き連れてくる。これでは単体テストになりませんッ！！😤」

② 実行速度の低下という「泥沼」

ルル： 「言語、特にPHPなどにおいては、こうしたstaticメソッドを無理やり外部から書き換えてテストしようとすると、テストケースごとに『プロセス分離（Process Isolation）』という非常に重い処理を走らせる必要が出てきます。あなたが『PCが重い』と言っていたのは、一つのテストを流すたびに、裏側でPHPの実行環境を丸ごと再起動させていたからですよッ！！😤」

サキがホワイトボードに心臓の絵を描いた。

サキ： 「ひま、想像してみて。心臓が胸の骨や筋肉とベッタリ一体化して固まってたら、マッサージもできないし、バイパス手術もできないでしょ？✨ テストっていうのは、一度心臓を体から切り離して、人工心肺（モック）に交換して動かしてみる実験なんだ。staticを多用したコードは、部品同士が溶け合って固まった心臓と同じ。メスを入れる隙間がないんだよ。✨」

♨️ staticを避けて「DI」という回路を通す ── しなやかな盾

ヒマリは、自分の書いた「便利なはずのコード」が、いかにメンテナンスの自由を奪っていたかを痛感した。

マリ： 「ヒマリちゃん。だからこそ、設計の回で学んだ『DI（依存性の注入）』が必要になるのよ。☕」

マリが静かに補足する。

マリ： 「staticで直接呼ぶのではなく、必要な機能をクラスのコンストラクタで『受け取る』ように変える。それだけで、コードに劇的な『しなやかさ』が生まれるわ。☕」

# DIを使った設計
class ArticleService:
    def __init__(self, auth_provider, permission_checker):
        self.auth = auth_provider
        self.permission = permission_checker

    def publish_article(self, article_id):
        user = self.auth.get_user() # staticではない
        # ...

ユイ： 「あぅ……っ。……これなら、テストの時に……本物のAuthクラスじゃなくて……『常に特定のユーザーを返す偽物』を、外からサッと渡してあげられるねぇ……っ。」

ユイの言葉に、ヒマリの目が輝きを取り戻した。 クラスをインスタンス化して「モノ」として扱う。たったそれだけのことで、あれほど苦労していたモック化が嘘のようにスムーズになり、プロセス分離という重い枷も外れるのだ。

ヒマリ： 「staticは便利さの裏に、テストの自由を奪う呪いがあったんですね。……。私、便利だからって安易に逃げるのをやめます。DIという回路をちゃんと通して、いつでも部品を交換できる、しなやかな盾を作ります！」

東根温泉の琥珀色の湯。その柔らかさは、決して固まることのない「しなやかさ」の象徴のようだった。 ヒマリの打鍵音は再び軽快になり、今度は「Running...」のプログレスバーが、瞬く間にGreenへと駆け抜けていった。

📜 ボスの秘蔵：設計の美学と現場のリアル

staticメソッドは、確かに便利です。 インスタンス化の手間もいらず、どこからでも手軽に呼び出せる。しかし、その「手軽さ」こそが、大規模なプロジェクトにおいては致命的な足かせとなります。

これまでの設計の連載でも触れてきましたが、私たちはDI（Dependency Injection）を基本に据えるべきです。 なぜなら、staticメソッドを内部で呼び出した瞬間、そのメソッドは呼び出し先と「密結合」してしまうからです。外部から切り離してテストしようとしても、staticメソッドという壁が立ちはだかり、依存関係の泥沼に引きずり込まれることになります。

技術的な側面から見れば、回避策がないわけではありません。 Pythonであればテスト実行時にメソッド自体を差し替えることができますし、PHPでもライブラリを駆使してstaticメソッドを強引に上書き（Override）することは可能です。

しかし、ここには大きな代償が伴います。 特にPHPでは本来メモリ上にロードされるべき「正しい定義」をテストのために歪めてしまうため、他のテストケースに深刻な副作用を及ぼすリスクが生じます。その副作用を避けるために「実行プロセスを分ける」という選択をせざるを得なくなり、結果としてテストの実行時間が膨れ上がっていく……。これが、前回お話しした「遅すぎるテスト」を生む元凶の一つなのです。

一方で、Laravelの「Facade」のように、staticなインターフェースを持ちながらもテスト時には Fake メソッドへ容易に切り替えられる仕組みを備えたものもあります。これはPythonの差し替えに近い利便性を提供してくれます。

ですが、これらはあくまで「救済措置」に過ぎません。 本質的には、staticメソッドに依存する設計そのものが密結合を招いている事実に変わりはないのです。

DIを軸に設計を行い、依存関係を外から注入する。 この「疎結合」を保つための規律こそが、クリーンアーキテクチャへと続く王道であり、変化に強く、かつ爆速で検証可能な「盾」を作り上げるための唯一の解ではないでしょうか。

（つづく）

#エンジニア #プログラミング #テストコード #ユニットテスト #設計 #DI #依存性の注入 #staticメソッド #密結合 #疎結合 #ソフトウェア開発 #リファクタリング #クリーンコード #PHP #Python #技術的負債 #東根温泉秘密結社 #テスト容易性