テスト駆動開発(TDD)とは何ですか?

large__8282043567テスト駆動型開発は、非常に短い開発サイクルの繰り返しに依存するプロセスです。 それは信頼の高レベルのシンプルな設計を励ます極度なプログラミング(XP)のテスト最初概念に基づいている。

TDDを実行する手順は次のとおりです:

  1. テストを書く
  2. すべてのテストを実行する
  3. 実装コードを書く
  4. すべてのテストを実行する
  5. リファクタリング

この手順は、多くの場合、Red-Green-Refactorと呼ばれ

テストを書いている間、私たちは赤の状態にあります。 テストは実際の実装の前に書かれているので、失敗することになっています。 そうでない場合、テストは間違っています。 それはすでに存在するか、間違って書かれたものを記述します。 テストを書いている間に緑色になっていることは、偽陽性の兆候です。 そのようなテストは削除またはリファクタリングする必要があります。

次は緑の状態になります。 最後のテストの実装が終了したら、すべてのテストに合格する必要があります。 そうでない場合、実装は間違っており、修正する必要があります。

アイデアは、実装を最終的にするのではなく、テストに合格するのに十分なコードを提供することです。 すべてが緑色になったら、既存のコードをリファクタリングすることができます。 つまり、新しい機能を導入せずにコードをより最適にしていることを意味します。 リファクタリングが行われている間、すべてのテストは常に合格する必要があります。 そのうちの一つが失敗した場合、リファクタリングは既存の機能を壊しました。 リファクタリングには新しいテストを含めるべきではありません。

スピードがカギ

large_5836417589
私は卓球(または卓球)のゲームとしてTDDを見る傾向があります。 ゲームは非常に高速です。 同じことがTDDにも当てはまります。 私はテーブルの両側(テストと実装)に1分以上費やさない傾向があります。 短いテストを書いて実行する(ping)、実装を書いてすべてのテストを実行する(pong)、別のテストを書く(ping)、そのテストの実装を書く(pong)、リファクタリングし、すべ ピンポン、ピンポン、ピンポン、ピンポン、スコアは、再び提供しています。 完璧なコードを作成しようとしないでください。 代わりに、時間が得点するのに適していると思うまでボールを転がし続けるようにしてください(リファクタリング)。

TDDで

tをテストすることではありませんが、誤解されることがよくあります。 TDDは、私たちが設計にアプローチする方法です。 これは、コードを書く前に実装について考えるように強制する方法です。 これは、コードをよりよく構造化する方法です。 これは、TDDを使用した結果のテストが役に立たないことを意味するものではありません。 それからは遠い。 彼らは非常に有用であり、私たちは何かが壊れてしまうことを恐れることなく、偉大なスピードで開発することができます。 これは、リファクタリングが行われるときに特に当てはまります。 機能が壊れていないという自信を持ちながらコードを再編成できることは、コードの品質を大幅に向上させます。

TDDの主な目的は、テストを非常に有用なサイドプロダクトとしてコード設計です。

モック

テストを高速に実行し、一定のフィードバックを提供するためには、メソッド、関数、クラスを簡単にモックしてスタブできるようにコードを整理する必要があります。 実行の速度は深刻なそれに影響を与えます、例えば、私たちのテストは、データベースと通信する必要があります。 外部の依存関係を嘲笑することで、その速度を大幅に向上させることができます。 単体テストスイート全体の実行は、数秒ではないにしても数分で測定する必要があります。 速度よりも重要なのは、コードを簡単に嘲笑してスタブできるように設計することで、懸念の分離を適用することによってコードをよりよく構造化する モックの有無にかかわらず、コードは、たとえば、あるデータベースを別のデータベースに簡単に置き換えることができる方法で記述する必要があります。 その”別の”は、例えば、嘲笑またはメモリ内のデータベースであることができます。

Scalaでのモックの例は、Scala Test-Driven Development(TDD):Unit Testing File Operations with Specs2and Mockitoの記事で見つけることができます。 選択したプログラミング言語がScalaでない場合でも、articleはどの言語にも適用できるパターンを見るために非常に便利です。

ウォッチャー

TDD方式で作業するときに非常に便利なツールはウォッチャーです。 これらは、作業を開始する前に実行され、コードの変更を監視しているフレームワークまたはツールです。 このような変更が検出されると、すべてのテストが実行されます。 JavaScriptの場合、ほとんどすべてのビルドシステムとタスクランナーがこれを許可します。 Gulp(私のお気に入り)とGruntは、多くの例のうち2つです。 Scalaはsbt-revolver(他の中でも)を持っています。 他のプログラミング言語のほとんどには、コードが変更されたときに(必要に応じて)再コンパイルし、すべての(または影響を受ける)テストを実行す 私はいつも私の画面を2つのウィンドウに分割することになります。 1つは私が取り組んでいるコードで、もう1つは継続的に実行されているテストの結果です。 私がしなければならないのは、それらのウォッチャーの出力が私がいるフェーズ(赤または緑)に対応することに注意することだけです。

Documentation

TDDのもう一つの非常に有用な副作用(および一般的によく構造化されたテスト)はdocumentationです。 ほとんどの場合、実装自体よりもテストを見てコードが何をするのかを知る方がはるかに簡単です。 他の種類のドキュメントでは提供できない追加の利点は、テストが古くなることがないということです。 テストと実装コードの間に矛盾がある場合、テストは失敗します。 失敗したテストは、不正確な文書を意味します。

ドキュメントとしてのテストの記事は、従来のドキュメントではなく、テストの使用の背後にある少し深い推論を提供します。

概要

私の経験では、TDDはおそらく私たちのソフトウェアツールボックスで持っている最も重要なツールです。 TDDに堪能になるには多くの時間と忍耐が必要ですが、その芸術が習得されると、生産性と品質が大幅に向上します。 TDDを学び練習する最良の方法は、ペアプログラミングと組み合わせて行うことです。 二人の参加者を必要とするピンポンのゲームのように、TDDは、一方のコーダーがテストを書き、他方がそれらのテストの実装を書くペアにすることができます。 役割はすべてのテストの後に切り替えることができます(コーディング道場で頻繁に行われるように)。

障害物が多いので、障害物に直面したときに試してみて、あきらめないでください。

テスト駆動開発(TDD):Javaの例を使用したベストプラクティスは、良い出発点です。 それはJavaの例を使用していますが、同じ、すべてではないにしても、慣行は、任意のプログラミング言語に適用することができます。 Javaの例(前のケースのように、他の言語に簡単に適用できます)については、TDDの例のチュートリアルの記事をご覧ください。

完璧なTDDスキルへのもう一つの素晴らしい方法は、コードkatasです(このサイトには多くのものがあります)。

TDDでのあなたの経験は何ですか? それを練習しているチームがあると私はあなたの経験について聞きたいと思いますと同じくらい多くのバリエーションがあります。

コメントを残す

メールアドレスが公開されることはありません。