01、はじめに
昔、彼がこれら三つの言葉、すなわち「テスト駆動開発」とはテスト駆動開発の頭文字であるアルファベットのネットワークTDD 3大文字に見ていたが - 素晴らしいものに聞こえますコンセプト。
アイデアは、二つのことを確実にするために、主に次のとおりです。
- すべてのニーズがするの世話をすることができていることを確認してください。
- コードの増加と復興過程では、あなたは正しくすべての機能かどうかを確認することができます。
しかし、その後、再びTDDメッセージを聞いたことがない、時間の長い期間、。一部の人々は次のようにTDD死んで、アドバイスを与えている、と言います。
1）一般的に、開発者は、失敗したテストケースコードなしで書かれるべきではない - 合理的なようだが、それは過度のテストにつながることができます。例えば、製品コードの行の正しさを保証するために、あなたは助けることが、生産のコード行を変更する必要があると、あなたはそれを4行のテストコードを変更する必要があることを意味し、テストコードの4行を記述することができませんでした。
2）TDDに従う、コード、誤解への容易なアクセスを書き込むために：実際の需要を無視してコードは、テストを満たすように設計されています。
02、TDDは、最終的に何ですか？
かかわらず、TDDの最後には死んでなくなって、私たちはそう最終的にどのようなTDDを見てみましょう。
TDDの基本的な考え方は、テストコードを書くための機能コードの開発の前に、あります。それは、関連するテストケースを満たしているコードを書いた後、この機能をテストする方法を考えると、筆記テストコードを完了し、すべての最初に、開発される関数の後に明らかである、と。その後、サイクルは、フル機能の開発が完了するまでは、他の機能を追加します。
TDDの基本的なプロセスは、6つのステップ以下に分解することができます。
1）需要の分析を、需要は特定のタスクに分割されます。
2）タスクリストからタスク、およびその書き込みテストケースを取り外します。
実際の機能コードがないため3）、テストコードは（赤）を通過する可能性はありません。
4）できるだけ早く対応する機能コード、試験コードの調製）緑色（によってように。
5）コードを再構成し、保証テスト（再構築）。
6）上記の手順を繰り返し。
なお、図の以下上述した処理によって表されます。
03、TDDの実践
通常の状況下での分析は、すぐにコードの機能の準備に可能プットとして、完了した後、我々は需要に慣れている、コールし、テストを行きます。
TDDは、我々が「テストユーザー」を持っていると仮定し、それは非常に完璧ではないものの、最初のユーザーの機能コード、機能コードです、異なっています。
私たちが立ったとき、「テストコードを書くために、ビューのテストユーザーのポイントを、我々は考慮する必要があり、この方法である」テストユーザーは、「機能コードを使用していますか？それは、その（静的メソッド）、または（インスタンスメソッド）を構築するためのメソッドを呼び出すためのクラスのインスタンスを行うには、クラスの直接的な方法を通じて呼び出されますか？どのように質量参加するこの方法は、でしょうか？方法に関係なく、それに名前を付けますか？メソッドは値を返しますか？
あなたがテストコードを持っていたら、私たちは関数のコードを書き始めると、「緑」、この時点でコードを機能することができるために、「赤」から最速の土地の速度テストを行うためには、非常にエレガントですが、それは大丈夫です。
コードの性能が元の比較的醜い、肥大化し、バリエーションの最適化 - テストが渡されると、私たちは大胆コード「復興」を機能させることを安心することができます。
次に、我々は開発ニーズを受け取ったとします。
樹皮チームが実行するアドベンチャーアイランドの町に行き、99元、冒険の島で唯一のプログラマ王のチケットは、チケットの売り上げを計算することができます小さなプログラムを開発する必要があります。
TDDのプロセスによると、王は、あなたが簡単なテストケースを書くことJUnitのを使用する必要があり、テストがあることが予想されます。チケットの販売収入は99元です。
public class TicketTest {
private Ticket ticket;
@Before
public void setUp() throws Exception {
ticket = new Ticket();
}
@Test
public void test() {
BigDecimal total = new BigDecimal("99");
assertEquals(total, ticket.sale(1));
}
}
コンパイルが渡すことができます容易にするために、王は単純なクラスのチケットが必要になります。
public class Ticket {
public BigDecimal sale(int count) {
return BigDecimal.ZERO;
}
}
図の試験結果は、以下のように、赤色のテストに合格しないである：期待される結果は、実際の結果が0であり、99です。
その後、次の、王は、すぐにテストパスを作成する必要がありTicket.sale()、次のようにメソッドの結果は更新日：
public class Ticket {
public BigDecimal sale(int count) {
if (count == 1) {
return new BigDecimal("99");
}
return BigDecimal.ZERO;
}
}
そして、テスト、以下のような結果を実行して、グリーンは、テストに合格したことを：期待される結果は99で、実際の結果は99です。
緑色、緑色、試験は、再構成関数のタイムコードに渡します。99元はマジックナンバーは、少なくとも右、定数として宣言されなければならないのですか？
public class Ticket {
private final static int PRICE = 99;
public BigDecimal sale(int count) {
if (count == 1) {
return new BigDecimal(PRICE);
}
return BigDecimal.ZERO;
}
}
彼らは、テストケースを実行した後の復興は、テストを通じ、その場合を確認し、[テストケースの数を増やすために、チケットの販売などは、ゼロあるいは千負です。
public class TicketTest {
private Ticket ticket;
@Before
public void setUp() throws Exception {
ticket = new Ticket();
}
@Test
public void testOne() {
BigDecimal total = new BigDecimal("99");
assertEquals(total, ticket.sale(1));
}
@Test(expected=IllegalArgumentException.class)
public void testNegative() {
ticket.sale(-1);
}
@Test
public void testZero() {
assertEquals(BigDecimal.ZERO, ticket.sale(0));
}
@Test
public void test1000() {
assertEquals(new BigDecimal(99000), ticket.sale(1000));
}
}
王は機能コードが例外をスローすることができます期待したときに売上高はマイナスであり、機能コードの結果がゼロであるべきゼロへの販売、千回を売却し、その結果は99000でなければなりません。
テストケースを再実行し、結果を以下に示します：
2つのテストケースは、王は次のように調整し、機能コードを変更し続ける必要があり、その後、合格しなかったがあります。
public class Ticket {
private final static int PRICE = 99;
public BigDecimal sale(int count) {
if (count < 0) {
throw new IllegalArgumentException("销量不能为负数");
}
if (count == 0) {
return BigDecimal.ZERO;
}
if (count == 1) {
return new BigDecimal(PRICE);
}
return new BigDecimal(PRICE * count);
}
}
そして、テストケースを実行して、我々はすべてが合格しました。次のように再構築、ゼロボリューム、以上のタイムコードに等しいが組み合わされてもよいので、復元結果へ再び時間は次のとおりです。
public class Ticket {
private final static int PRICE = 99;
public BigDecimal sale(int count) {
if (count < 0) {
throw new IllegalArgumentException("销量不能为负数");
}
return new BigDecimal(PRICE * count);
}
}
再構成後、リファクタリングコードがまだ使用可能であることを確認するためにテストケースを再実行します。
最終的には04、
上記の方法の実施から、我々は次のような結論を引き出すことができます。
TDDはやりたい私たちは、このコードがテストコードで正しいかどうかを判断することができるので、自信を持って私たち自身のコードを作るです。
これは、TDDのプロセスをより重要な部分は、有効なテストコードを書く方法で、4つの原則があり、あるを参照することができます：
1）テストプロセスは、通常の使用の過程をシミュレートしてみてください。
2）できるだけブランチカバレッジとして必要があります。
3）試験データは、実際のデータと境界データを含めるようにしてください。
4）テスト文とテストデータは、シンプルで理解しやすいはずです。
また、テスト・プロセスの下で任意の単位に適用され、これらの4つの原則だけでなく、TDDに適用されることに注意してください。
最後に、私は、デッドTDD存在しないに関係なく、TDDはすべてのシナリオに適合しない、銀の弾丸ではないと言いたいが、これは、我々はそれを拒否した理由ではありません。