ソフトウェア開発の世界では、単にテストを書くことはテストを介して開発することに等しいという一般的な誤解があります。
開発によるテスト（TDD）により、プログラムがいつでも動作するという自信が得られ、すべてのパーツが適切に設計、再利用、疎結合されるようになります。
TDDとは何ですか？
TDDには、 Uncle Bobからの3つの基本的なルールがあります。
- テストするコードのみを記述します。
- 小さなテストの作成を開始し、それらを構築します。
- テストに合格するために必要なだけのコードを記述します。
TDDの基本
TDDの基本的なフォローアッププロセスは、 赤、緑、リファクタリングの3つのステップで構成されています。
赤
レッドステージでは、失敗するテストを作成します。 1つのテストのみ。 停止して多くのテストを書き続けることができない場合は、 Getting Things Doneのアイデアを取り入れて、頭から余分な考えを引き出して、気が散らないようにします。 使用できる方法はいくつかあります。紙の上にTo Doリストを作成する、インデックスカードを描く、一連のTODOコメントをファイルに追加する、その他多くの方法があります。 私自身は、紙の上で流行を消したり、チェックマークを描いたり、インデックスカードを半分に折ったりするという物理的なアクションが、より大きな完成感をもたらすと判断しました。
新しい施設の最初のテストは簡単なはずです。 TDDは、 新しいデザインに焦点を当てています。これは、 先の大規模デザインの反対です。 コードからデザインを作成してみましょう。 最初のテストの目的は機能ではなく、現在作成しているものを使用する境界を定義することです。
はじめに、「このアクションに何を伝えますか？」 その後、結果について考えます。「この関数は何を返しますか？」 推測を書き、テストを実行し、新しいテストが赤であることを確認します。
レッドステージの他のすべてのテストケースは、開発された機能に焦点を当てる必要があります。 単純な道をたどらないで、関数またはオブジェクトでできる最も予測不可能なことを考えてください。 nullパラメーターを渡すとどうなりますか？ 負の数を渡すとどうなりますか？ コードが数値を期待しているときに文字列を渡すのはどうですか？
緑色
緑の段階は、落下試験にできるだけ早く合格することです。 複数のテストがクラッシュする場合は、作成したばかりのテストを修正してから、他の赤いテストを1つずつ修正し続けます。 コードがどのように見えるか、それがどれほど効果的であるかを考えないでください。 機能の別の部分がテストでカバーされていることを確認できるように、テストに合格することが目標です。
リファクタリング
次のステップは、コードのリファクタリング、再構築、および整理です。 リファクタリングフェーズはいつでも発生する可能性があります。1回の赤/緑のサイクルの後、4回以上の後。 少なくとも1つのグリーンテストがあるので、ミスを犯して機能しなくなった場合にテストが失敗することを知って、簡単かつ快適にコードを書き換えることができます。
リファクタリングは、コードの再構築と、より読みやすい外観にすることのみに関係します。 テストの改善に注意を払うことを忘れないでください。ただし、コードとテストを同時にリファクタリングしないでください。
TDDの利点
作業コード
TDDの利点の 1つは、正常に機能するコードを常に利用できることです。 コードのパフォーマンスに時間を費やし、常に意図したとおりに機能することを確認できます。
恐れることなく変わる
TDDにより、変更を恐れることがなくなります。 TDDの利点に気付く前に、多くのプロジェクトに取り組みました。 振り返ってみると、私はいつもコードを変更することを恐れていたと言えます。 パフォーマンスを損なわないことを確認するために、アプリケーションを手動でテストするのに多くの時間を費やしました。 TDDの出現により、この恐怖はなくなりました。機能は常にテストでカバーされ、システムまたはその一部からほぼ瞬時に応答を得ることができます。 同時に、リファクタリングへの恐怖がなくなると、プログラムの内部品質が向上し、外部品質にプラスの効果があります。
ライブドキュメント
TDDは、ライブコードのドキュメントを提供します。 あなたが私と同じなら、新しいライブラリの研究はふわふわしたドキュメントではなく、使用例から始まります。 テストを記述またはリファクタリングするときは、テストの可読性とアルゴリズムのシンプルさを維持する必要があることを理解して従うことが非常に重要です。 コメントや長いドキュメントとは異なり、テストは実行可能であり、いつ嘘があるかを常に知らせます。
コードによるアーキテクチャ
私は、TDDのDの1つがデザインを意味しないことを常に心配していました。 前に簡単に述べたように、TDDの実践は、プログラムが機能することを確認するためのテストを書くことだけではありません。 TDDはソフトウェア開発をひっくり返し、内部からではなく外部から問題について考えさせます。
テストを作成しても、実装について考えることはありません。主な関心事はオブジェクトまたは関数の使用です。 私たちが書くオブジェクトや関数と直接やり取りするのに多くの時間を費やすため、アーキテクチャはコード自体から現れます。
TDDではない場合
新しいライブラリまたはフレームワークを使用する必要があるが、その方法がわからない場合はどうなりますか？ どこから始めればよいかわからない場合、最初にテストを書くにはどうすればよいですか？ 答えは簡単ですが、できません。 新しいプロジェクトを作成し、作業コードとは別に新しいライブラリを使用します。 そのような新しいプロジェクトは松葉杖と呼ばれます。 作業コードには含まれていないため、ボブおじさんの3つのルールのルール1に違反することはありません。 このライブラリの使用に慣れるまで、彼と協力してください。 ライブラリの動作を確認したら、松葉杖を忘れて作業コードに戻り、テストの作成から始めます。
ただし、TDDを使用できない場合は、テストを書くことの重要性を忘れないでください。 あなたのテストは、あなたのためのリファレンスとして機能します（あなたの松葉杖がバージョン管理システムにある場合）あなたの後に来る人のために。 これらのテストを使用すると、学んだことをすぐに思い出すことができ、振り返ってみるとスキルの大きな進歩が見られます。