第27回：【テストコードのガイドライン その2】AAAの規律 ── レビューを殺す「実況中継」を卒業せよ

♨️ ヒマリの「完璧（だと思っている）」テストコード

東根温泉支部の朝は、立ち上る湯気のように静かで穏やかだ。しかし、開発室の一角だけは、ヒマリの弾むような打鍵音が心地よいリズムを刻んでいた。

前回の連載で、テストが「自分自身の不安を解消するメモ」から「顧客に対する品質の盾」へと進化したことを学んだヒマリ。彼女は今、その「盾」を自分自身の手で鍛え上げることに、かつてない喜びを感じていた。

ヒマリ： 「……よし！ 完璧。メソッドごとにテストを完全に分離。命名も仕様通り。これですよ、これ！」

満足げに背伸びをしたヒマリの元に、コーヒーの香りを漂わせながらサキがやってくる。

ヒマリ： 「サキ先輩、見てください！ 前回の教え通り、メソッドごとにテストをしっかり分けました。これなら、どこでバグが起きても一発でわかります。私、ついにテストの真理、その入り口に辿り着いたかもしれません！」

ヒマリが意気揚々と差し出したエディタ画面を、サキは目を細めて眺める。整然と並んだテストメソッドの名前は確かに美しい。しかし、個別のメソッドの中に視線を移した瞬間、サキの眉が少しだけ動いた。

サキ： 「おー、やるじゃん。確かにメソッドの切り出しはいい感じ。……。でもさ、ひま。この中身、なんか『刻んで』ない？ 読んでて、こう……息が切れるんだけど。✨」

♨️ ステップ実行のような「実況中継型」テスト

サキの指摘に、ヒマリは首を傾げる。「刻んでいる」とはどういうことか。ヒマリの書いたテストコードは、次のような構成になっていた。

def test_calculate_total_price():
    # 商品データを用意
    data = {'id': 101, 'price': 1000, 'tax_rate': 0.1}
    # 代入できたか、まずは確認
    assert data['id'] == 101 
    
    # 計算ロジックを呼び出す
    logic = PriceCalculator()
    result = logic.calculate(data)
    
    # 計算結果がちゃんと返ってきたか確認
    assert result is not None
    
    # ステータスが成功か確認
    assert result.status == 'success'
    
    # 最終的な金額が合っているか確認
    assert result.total == 1100

ルル： 「（背後からこめかみを指でトントンと叩きながら）……ヒマリさん。これはテストコードではありません。ただの『デバッグの足跡』ですッ！😤」

突然現れたルルの鋭い声に、ヒマリは背筋を伸ばす。

ヒマリ： 「足跡……ですか？ でも、1ステップずつ確認したほうが、どこで間違えたかすぐわかるじゃないですか。親切だと思って入れたんですけど……。」

ルル： 「それがレビュワー殺しなのですッ！ あなたのコードは、まるでマラソンコースの1メートルごとに『今、地面を踏みました』『今、呼吸をしました』と報告しているようなもの。読み手は、あなたが最終的にどのゴールを目指し、何を確認したいのか、最後まで迷路を歩かされる羽目になります。これは品質の証明ではなく、単なるあなたの『実況中継』に過ぎませんッ！！😤」

ヒマリは言葉に詰まった。良かれと思って入れた丁寧なアサーションが、逆にコードの可読性を著しく損なわせ、レビュワーの集中力を削いでいたことに気づかされたのだ。

♨️ AAAの順守 ── 物理的な「型」がレビューを救う

項垂れるヒマリに代わって、マリが優しくエディタのキーボードに手を添えた。

マリ： 「ヒマリちゃん。テストコードには、読み手に対する『礼儀』としての物理的な型があるのよ。それが、AAA（Arrange / Act / Assert）。☕」

マリはヒマリのコードに、2つの空行を入れた。それだけで、コードの「景色」が劇的に変わった。

Arrange（準備）：舞台を整える

まず、テストに必要なデータを揃える場所。ここではまだ、何も「実行」しない。

Act（実行）：主役の出番

テスト対象となるメソッドを、ただ一行だけ呼び出す。ここがテストの心臓部。

Assert（検証）：検品

最後に、届いた結果を一気に検品する。

サキ： 「ひま、ここが大事なんだけどさ。✨ 道中の小石を一つずつ確認しなくていいの。途中で assert を入れちゃうのは、実は自分の書いた準備コード（Arrange）を信用してない証拠なんだよ。✨」

サキの言葉が、ヒマリの胸を突く。

サキ： 「準備が正しくできている前提で、Actを叩く。そして最後の一撃（Assert）で、すべての辻褄が合っているかを見る。それが『検証』の品格ってもんじゃん。道中でこまごま確認するのは、自信がないプログラマがやる『甘え』だよ。✨」

特に昨今、AIにプロンプトを投げてテストコードを生成させると、AIは得てして「実況中継型」のコードを量産しがちだ。 1行進むごとに「値が正しいか」を律儀に確認するAI。それをそのままレビューに出せば、人間側の認知負荷は爆増する。

だからこそ、人間が「AAAの型で書け」「アサーションは最後の一塊に集約せよ」という規律を、プロンプトという名の鉄の掟で死守しなければならないのだ。これは、現場で何万行ものコードを見てきたエンジニアたちの、切実な知恵である。

♨️ アサーションの集約 ── 「一言」で言い切る勇気

AAAの構造を整えた後、マリは最後のアサーション部分を指差した。

マリ： 「理想は、1つのテストメソッドにつき、アサーションは1つ。でも、現実のシステムでは1つの結果を多角的に見たいこともあるわ。その場合は複数並べても構わない。けれど、『過程の確認』は徹底的に排除すること。☕」

ヒマリは、マリに教えられた通りにコードを書き直してみた。

def test_calculate_total_price():
    # Arrange: 準備
    data = {'id': 101, 'price': 1000, 'tax_rate': 0.1}
    logic = PriceCalculator()

    # Act: 実行
    result = logic.calculate(data)

    # Assert: 検証
    assert result.status == 'success'
    assert result.total == 1100

ユイ： 「あぅ……っ。……綺麗。最後のアサーションのブロックを見ただけで、このテストが何を保証したい『仕様書』なのか、一目でわかるようになったねぇ……っ。」

ずっと静かにモニターを見つめていたユイが、嬉しそうに呟く。 空行で区切られた三段構成。そして最後の一塊に集約されたアサーション。 それはもはや単なるプログラムではなく、その機能がどのような挙動をすべきかを雄弁に語る「ドキュメント」に昇華されていた。

ヒマリ： 「三段構えのAAA……。この型を崩さないことが、自分勝手な安心を捨てて、未来のレビュワーに安心を届ける一番の優しさなんですね。」

ヒマリは、エディタに映る「整理された盾」を誇らしく見つめた。 1ステップずつ確認しなければ不安だった自分は、もうそこにはいない。 適切な準備をし、一撃で結果を出し、堂々と検品する。

東根温泉の琥珀色の湯から立ち上る湯気が、窓の外の夜景を柔らかく包み込む。 開発室には、規律を身につけ、一歩ずつプロへの階段を上るヒマリの、再び軽快になった打鍵音が響き渡っていた。

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

テストコードを書き始めた頃、私が真っ先にぶち当たった壁は「一体、何をテストしたいのか？」という自問自答でした。

「準備した変数は、この時点で正しくセットされているか？」 「このステップでは、値は想定通りに遷移しているか？」 「……よし、値は合っている。これならメソッドを叩けば、期待通りに動くはずだ……」

そんなふうに考えていた時期が、私にもありました。気づけば、肝心のメイン処理をテストする前に、延々とアサーション（検証）を繰り返す。そんな「心配性の塊」のようなコードを量産していたのです。今思い返すと、少し恥ずかしく、遠い目になってしまいます。

実際、そうした「道中の実況中継」が混ざったテストコードは、後から読み返すと「結局、このテストは何を確認したかったのか？」が、ノイズに埋もれて全く見えてこなくなります。

その迷いを断ち切るために必要なのが、AAA（Arrange / Act / Assert）という規律です。

1. Arrange（事前準備）: 舞台を整える

2. Act（実行）: 劇を始める

3. Assert（検証）: 幕が下りた後の結果を確認する

この3ステップが物理的に守られたテストコードは、驚くほど読みやすく、誰が見ても「意味のあるテスト」へと昇華されます。

ちなみに、設計のシリーズでも触れましたが、メソッドが「単一責任の原則（SRP）」を遵守しているかどうかは、このAAAのシンプルさに直結します。

もし、単一責任を守らずに「あれもこれも」詰め込んだ肥大化したメソッドであれば、AAAの「検証（Assert）」のフェーズで、複数の、あるいは無関係な結果を一度に検品しなければならなくなります。そうなれば、テストコードは再び読みづらさを増し、品質の証明としての力を失っていくでしょう。

テストをシンプルにするために、設計を研ぎ澄ます。 設計を正しく行うために、テストコードの書き方を学ぶ。 「設計」というパズルの最後のピースは、このAAAという規律によって、カチリと音を立ててはまるのだと、私は考えています。

（つづく）

#エンジニア #プログラミング #テストコード #ユニットテスト #AAA #設計 #単一責任の原則 #SRP #ソフトウェア開発 #品質保証 #QA #生成AI #AI活用 #リファクタリング #クリーンコード #東根温泉秘密結社 #ボスの秘蔵 #駆け出しエンジニアと繋がりたい