テスト駆動開発を学ぶ

序文

コンピュータサイエンスとソフトウェア工学の教育者としての私の30年のキャリアを通じて、特に2001年に短期間産業界に身を置いて以来、テスト駆動開発（TDD）が特定の、しかし広く適用可能なテクニックに運用化する一般的なアプローチである自動単体テストほど、私の教育（および研究）を形成し、浸透させたテクニックは他にあまりない。 。

オブジェクト指向開発コースのUMLリファレンスとして、マーティン・ファウラーの2003年のテキスト『UML Distilled』（第3版）を採用した後、ほとんど副次的な意味で、TDDを具体的に理解したことを今でも覚えている。 そこでマーティンは、成功する反復開発プロセスで通常発見される3つの重要なプラクティス、自動回帰テスト、リファクタリング、継続的インテグレーションについて論じている。この簡潔な説明は私の心に強く響いた。私はいつも、残りのコードをテストするために追加のコードを書き、カラフルなテスト結果という形で即座にフィードバックを受け取ることで、生徒たちにもっと楽しむように説得することを楽しんできた。

もうひとつのハッとした瞬間は、それから10年近く経った2012年頃、ソフトウェア・アーキテクチャに関するSoftware Engineering Radioのポッドキャストを聴き始めたときに訪れた。そのポッドキャストで言及されていた文献のいくつかを読み取り、"ボブおじさん "ことロバート・C・マーティンの著書『Agile Software Development』の「Serendipitous Architecture（セレンディピタスアーキテクチャ）」と題された短い小節を見つけた：原則、パターン、プラクティス』では、コードをテスト可能にすることに集中することで、保守可能な優れたアーキテクチャがほぼ自動的に得られると論じている。

これらの2点をまとめると、自動化された機能テストがプロセスとアーキテクチャ、そして機能要件と非機能要件を結びつける方法が浮き彫りになる。コードがどの程度機能要件を満たしているかに確信を持つことで、テスト容易性は間違いなく最も重要な非機能要件になる。

それからさらに10年近く経った今年の夏、サリーム・シディキから著書の件で連絡があった。ちなみに、サリームが私のもとで3つの大学院レベルのコースを受講してから、来年で25周年になる！彼がテクノロジーのプロフェッショナルとして、Martin FowlerのようなThoughtworkserとして、そして著者として成功するのを見るのは、非常にやりがいのあることだった。彼の本に序文を書くよう頼まれたことを光栄に思うとともに、彼のTDDに対する考え方についてもっと知りたいと思った。

サリーム氏の本で私が最も興奮したのは、日常生活で非常に馴染みのある実例を使って、実践的でありながら理路整然とした方法で読者をTDDプロセスに巻き込んでいる点だ。赤-緑-リファクタリングのサイクルは、プログラミング言語に関係なく、プロセスの基調となる。金融通貨の領域から連続する機能は具体的で親しみやすいが、読者を徐々に複雑な課題へと導き、それによって自信を深め、微妙なトレードオフを明らかにし、さらに探求したいという好奇心を呼び起こす。最終的なコードレビューは、プロファイル、目的、プロセスの3つの次元に沿って行われ、その過程で得られた洞察を統合している。

JavaScriptとPythonはすでに市場でトップの地位を占めており、Goは急速に台頭しつつある。Saleemは、むしろ補完的な設計を持つ、非常に注目度の高い3つの言語を使用することで、TDDアプローチの幅広い適用可能性を力説している。さらに、彼は読者に対して、言語設計と前述の「3つのP」との関係について、さらなるタッチポイントと気づきを与えてくれる。 ...