「Agile Design with TDD」を読んだ – Carlos Blé著

はじめに

この記事を始める前に、私の学習経験について説明します。上級課程の学習中に、C#でのテストをVisual Studioを使って非常に短く触れたことがあります。これらのテストは既存のコードに対して行われたもので、当初はテストはある方法で行うものだと考えていました。しかし、この本を通じて、私がまったく知らなかった多くの方法があることを学びました。

TDDとは何か？

本によると、TDDは、多くのプログラマーが通常コードを書き始め、後でテストを作成することを示しています（経験の少ない人は、コードが完成した後にテストを作成し、リファクタリングによる変更が正しいかどうか自動的に確認する方法だと思うでしょう）。しかし、私の解釈は間違っており、本によればテストは最初に、テストを通すために必要な最小限のコードで作成すべきだと説明されています。複数のテストを作成し始めると、多くのことに気付き、それらを再利用可能な形で整理できます。その時点でテストコードのリファクタリングを行うべきです。こうして、TDDは「書く-テスト-リファクタリング」の継続的サイクルであることがわかります（本では「赤-緑-リファクタリング」と呼ばれています）。

本書で紹介される例のテストは、前半では非常に理解しやすいですが、Mockの部分が出てくると複雑になります。

リファクタリングは良いことだが、やりすぎは禁物という視点があるのも良いと思いました。開発初期の段階で複雑さや抽象化を追加すると逆効果になる可能性があります。本から引用すると以下の通りです：

「リファクタリングは行うが、適切な量とタイミングで行うこと」

ページ 37

TDDをいつ使うか？

すでに進んだ開発にTDDを適用するのは逆効果です。本から理解したことは、TDDは単なるツールではなく、テストファーストに基づく方法論であるということです（TDDとテストファーストは同じではなく、TDDはその後のリファクタリングも含む概念です）。

TDDは、問題をサブ問題に分け、それらを複雑さの順に段階的に解決することを促します。このタイミングでペアプログラミングを実践するのが最適です。私もLeanMindのオフィスでの最初のコーディング道場で無意識に学びました（これは別の記事で詳しく書きます）。

「コードに執着すると、変更や削除を恐れるようになるが、時には一部分のコードをデバッグするよりも削除して最初からやり直す方が生産的であることもある。」

この状況に何度も直面しましたが、作業を削除してほぼゼロからやり直す勇気は評価されることが少ないです。TDDは態度でもあります。

結論と学んだこと

本書から学んだもう一つのことは、本を読んだりTDDでプロジェクトを行っただけでは専門家になれないということです。習慣を身につけるには時間、努力、意志が必要です。

では、この本は何のために役立つのか？主にTDDを取り巻く方法論を理解し、テストの作成方法を学び、異なる言語でのテストを比較し、テストを始めるための人気ツールを知り、そして何よりTDDにおける協調的な考え方を学ぶことです。

この本で初めて知った概念の一つは**エンドツーエンドテスト（E2E）**です。これまで私は、単体テストしか知らず、特定のタスクに焦点を当てて結果を確認するだけでした。

本書の前半は私の知識レベルに最も適していると思います。Mockのような高度な概念を知らなくても理解でき、将来のプロジェクトでTDDを実装するための指針を提供してくれます。

Carlos Blé に感謝します。本書で紹介された業界の著名なプロフェッショナルたち（以前は知らなかった人たち）もフォローし始めました：Robert C. Martin、Peter Kofler、Rob Myers、Matt Wynne。TDDの哲学を理解し、向上させたい方には強くおすすめします。