テスト駆動開発を学ぶ

序文

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

テスト駆動開発とは、プログラミング中の恐怖を管理する方法である。

ケント・ベック

私たちは本当に幸運だ！我々は何年もテスト駆動開発をしてきた。

マーキュリー宇宙計画のコードを書き込んだ開発者たちが、パンチカードTDD（テスト駆動開発）を実践してから数十年が経過した。テスト駆動開発の採用を促進するXUnitライブラリの歴史は、今世紀にさかのぼる。実際、ケント・ベック（Kent Beck）は『テスト駆動開発（Test-Driven Development：By Example』（Addison-Wesley Professional、2002年）を執筆し、JUnitフレームワークを開発したケント・ベックは、TDDの実践を（発明ではなく）「再発見」したと自称している。この文は彼の謙虚さの証拠であり、同時に真実でもある。TDDは、ソフトウェア開発そのものと同じくらい古いものだ。

ではなぜ、テスト駆動開発はいまだにコードを書く標準的な方法からほど遠いのだろうか？スケジュールのプレッシャーがあるとき、IT予算を切り詰める必要があるとき、あるいは（個人的に好きなのだが）「ソフトウェアデリバリーチームの速度を上げたい」という願望があるとき、なぜテスト駆動開発が最初に犠牲にされることが多いのだろうか？TDDが不具合のカウントを減らし、よりシンプルな設計を作成し、開発者のコードに対する自信を向上させるという経験的・ 実験的証拠がすぐに利用できるにもかかわらず、これらの理由はすべて提示される。

なぜTDDは不承不承採用され、すぐに放棄されるのだろうか？実践に消極的な人々からよく聞かれる以下の引数が、その理由を説明するかもしれない：

どこから、どうやって始めたらいいのかわからない。

おそらく最も一般的な理由は、認識不足と露出不足だろう。他のスキルと同様に、テスト駆動スタイルでコードを書くことは学ぶ必要がある。多くの開発者は、このスキルを習得するための外的な誘因（時間、リソース、指導、励まし）や内的な動機づけ（自分自身の消極性や恐怖に打ち勝つ）を得ていない。

TDDは、おもちゃのプログラムやコーディング面接では機能するが、"現実世界 "のコードを書くときには機能しない。

これは真実ではないが、理解できる。この本を含め、テスト駆動開発のチュートリアルや本のほとんどは、明らかなドメインから比較的単純な例を選ぶという制約がある。商業的にデプロイされたアプリケーション（金融機関、医療管理システム、自動運転自動車など）から抜き出したソフトウェアの実際のコードを使って、TDDの記事や本を書くのは難しい。ひとつには、このような実世界のコードの多くはプロプライエタリであり、オープンソースではないからだ。もうひとつは、最大の聴衆に最も広くアピールできる領域のコードを示すことが著者の仕事だということだ。高度に特殊化したドメインの文脈でTDDを示すのは、曖昧主義に近い非論理的なことだ。そうするためには、何よりもまず、その領域の難解な専門用語や専門用語について長々と説明する必要がある。それでは、TDDを理解しやすく、親しみやすく、愛すべきものにする、という著者の目的そのものが台無しになってしまう。

TDDの文献で実世界のコードを使用することに対するこのような障害はともかく、開発者は定期的にテスト駆動開発を使って量産ソフトウェアを書いている。おそらく最も説得力のある例は、 ...