Pythonによるテスト駆動開発, 3rd Edition

第4章 これだけのテストを何のために やっているのか？（そしてリファクタリング）

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

TDDの基本を実際に動かしてみせたところで、 一旦立ち止まって、なぜこれを行うのかを話そう。

読者の諸君の中には、今まさに 抑えきれない苛立ちを抱えている者もいるだろう。 もしかすると、以前少しだけ単体テストをしたことがある者もいれば、 単に急いでいる者もいるかもしれない。 君たちはこんな疑問を飲み込んできたはずだ：

• これらのテストは少し過剰ではないか？

• 確かにいくつかは重複しているのでは？ 機能テストと単体テストの間で重複がある。

• あの単体テストは明らかに些細すぎる——定数を返す一行関数をテストするなんて！ 時間の無駄じゃないか？ もっと複雑なことにテストを集中させるべきじゃないのか？

• 単体テストとコードの往復で生じる細かい変更はどうするんだ？ 最初から最後まで一気に進められないのか？つまり、home_page = None ！？マジかよ？

• まさか、実際にこんな風にコードを書いてるわけじゃないだろうな？

ああ、若き弟子よ。私もかつては同じ疑問に満ちていた。 だがそれは、それらが正当な疑問だからに他ならない。 実際、今でも私は常にこうした疑問を抱いている。 これらは本当に価値があるのか？　単なるカーゴカルトではないのか？

プログラミングは井戸からバケツで水を汲み上げるようなものだ

結局のところ、プログラミングは難しい。多くの場合、我々は賢いから成功する。 TDDは、我々がそれほど賢くない時に助けてくれるものだ。 TDDを実質的に発明したケント・ベックは、ロープで井戸からバケツの水を引き上げるという比喩を使っている：井戸が深すぎず、バケツがあまりいっぱいじゃない時は簡単だ。 満杯のバケツでも、最初はかなり楽に上げられる。 だがしばらくすると、疲れてくる。 TDDは、進捗を保存できるラチェットのようなものだ。 休憩を取っても、決して後退することはない。

そうすれば、常に頭を使う必要はない（図4-1参照）。

図4-1. あらゆるものをテストせよ （Allie Brosh『Hyperbole and a Half』より改変）

さて、おそらく一般性ではTDDが良い考えだと認めるだろう。 それでもまだ、俺がやりすぎだと思っているかもしれない？ ごく小さなことをテストし、途方もなく多くの小さなステップを踏むなんて？

TDDは訓練だ。つまり自然につくものではない。 多くの見返りは即座には得られず、長期的にしか現れないから、 その瞬間に自らを強制しなければならない。 それが「テストヤギ」のイメージが表すものだ—— そこには少し頑固な意志が必要だ。

些細な関数に対する些細なテストの価値について

短期的には、単純な関数や定数にテストを書くのは少し馬鹿げているように感じるかもしれない。

「ほぼ」TDDを実践しつつ、 すべてを単体テストしないという緩い規則を守ることも十分考えられる。 だが本書では、完全かつ厳密なTDDの実践を示すのが目的だ。 武道の型のように、困難のない制御されたコンテキストで動作を学び、テクニックを筋肉記憶に刻み込むのが狙いだ。 ...