私は VS 2012 を使用していますが、それはあまり重要ではありません。
重要なのは、最初にすべてのテストを作成してからコードを作成することで、TDD を実行しようとしているということです。
ただし、オブジェクトまたはメソッドが存在しないため、アプリはコンパイルされません。
今、私の考えでは、すべてのテストを作成できるはずですが、アプリを実行してデバッグなどを行うことができます。オブジェクトとメソッドが欠落しているため、テストによってコンパイルが妨げられるべきではありません。
要点は、テストを開発するにつれて、重複などを確認できるようになり、コードを 1 行書く前にリファクタリングできるようになるということだと思いました。
問題は、これを行う方法はありますか、それとも間違っていますか?
編集 私はVS2012とC#を使用しています
小さな問題が見られます
最初にすべてのテストを書き、次にコードを作成します。
最初にすべてのテストを作成する必要はありません。必要なのは、1 つだけで、失敗させ、成功させ、繰り返すだけです。つまり、理想的には、どの時点でも、理想的には失敗したテストが1 つあるはずです。
その意味では、コンパイルの失敗は失敗したテストとしてカウントされます。つまり、スタブを追加するか、デフォルト値を返してコンパイルします。テストは赤になり、緑になるように作業します。
テスト駆動開発は、非常に小さな反復です。すべてのテストを前もって定義するわけではありません。1 つの要件の一部に基づいて 1 つのテストを作成します。次に、そのテストに合格するコードを実装します。合格したら、要件の別の部分に取り組みます。
すべての設計を前もって (詳細なクラス図を作成する場合でも、多数のテストを作成する場合でも) しようとすると、設計の弱点を変更するにはコストがかかりすぎることがわかり、改善されないという考えです。コード。
これが例です。たとえば、継承を使用して 2 つのオブジェクトを関連付けることに決めたものの、オブジェクトの実装を開始したときに、それらのテストが困難であることがわかったとします。各オブジェクトを個別にテストし、代わりに封じ込めを介してそれらを関連付ける方がはるかに簡単であることがわかります。起こっていることは、テストが設計をより疎結合の方向に動かしているということです。これは TDD の非常に良い結果です。テストを使用して設計を改善しています。
継承の設計上の決定が適切であると仮定して、すべてのテストを事前に作成していた場合、多くの作業を放棄するか、「今そのような変更を行うのは難しすぎるので、代わりに、この次善の設計を受け入れるだけです。」
確かに、ビジネス ルール関連の受け入れテストを事前に作成できます。これらはビヘイビア テスト (ビヘイビア駆動開発 (BDD) の一部) と呼ばれ、ユーザーの観点からソフトウェアの機能をテストするのに適しています。しかし、それらは単体テストではありません。単体テストは、開発者の観点からコードをテストするためのものです。事前に単体テストを作成すると、TDD の目的が損なわれます。テストが難しくなり、コードの改善が妨げられ、多くの場合、反抗や実践の失敗につながるからです。だからこそ、正しく行うことが重要です。
重要なのは、最初にすべてのテストを作成してからコードを作成することで、TDD を実行しようとしているということです。
問題は、「最初にすべてのテストを作成する」ことは、「いくつかの TDD を実行する」ことではないということです。テスト駆動開発は、「赤-緑-リファクタリング」サイクルの小さな繰り返しで構成されます。
事前に巨大なテスト スイート全体をコーディングすると、"グリーン" (すべてのテストがパスする) 状態に到達するために永遠に費やすことになります。
ただし、オブジェクトまたはメソッドが存在しないため、アプリはコンパイルされません。
これは、コンパイルされた言語の典型です。それ自体は TDD の問題ではありません。つまり、新しいテストが失敗するのを見るには、コンパイラを満足させるために現在取り組んでいる機能の最小限のスタブを作成する必要があるかもしれません。
たとえば、次のテストを (NUnit を使用して) 記述します。
[Test]
public void DefaultGreetingIsHelloWorld()
{
WorldGreeter target = new WorldGreeter();
string expected = "Hello, world!";
string actual = target.Greet();
Assert.AreEqual(expected, actual);
}
そして、アプリをコンパイルしてテストを失敗させるには、次のような多くのコードを記述する必要があります。
public class WorldGreeter
{
public string Greet()
{
return String.Empty;
}
}
ビルドするソリューションを取得し、1 つの失敗したテストを確認したら、最初のテストに合格するコードを追加できます。
public string Greet()
{
return "Hello, world!";
}
すべてのテストに合格したら、テスト対象のシステムを調べて、設計を改善するために何ができるかを確認できます。ただし、リファクタリングをいじる前に、「赤」と「緑」の両方の手順を実行することが、TDD 規律にとって不可欠です。
要点は、テストを開発するにつれて、重複などを確認できるようになり、コードを 1 行書く前にリファクタリングできるようになるということだと思いました。
Martin Fowler は、リファクタリングを「既存のコード本体を再構築し、外部の動作を変更せずに内部構造を変更するための訓練された手法」と定義しています(強調を追加)。コードを 1 行も書いていなければ、リファクタリングする必要はありません。
問題は、これを行う方法はありますか、それとも間違っていますか?
あなたがTDDをやろうとしているなら、そうです、私はあなたがこれを間違っているのではないかと心配しています. あなたがやっていることを実行する素晴らしいコードを提供できるかもしれませんが、それは TDD ではありません。それが問題かどうかは、あなたが自分で決めることです。
スタブ関数を使用して空のクラスを作成できるはずですよね?
class Whatever {
char *foo( const char *name ) {}
int can_wibble( Bongo *myBongo ) {}
}
その後、コンパイルできます。
いいえ。必要なユースケースの実装を検証するのに十分なだけのコーディングに関するものです。
テスト ケースを早い段階で定義することはできますが、テスト ケースをコーディングするには、繰り返しテストを作成し、失敗させます。次に、コードが確実に通過するようにするコードを記述します。
次にすすぎ、すべてのテスト ケースがカバーされるまで繰り返します。
コメントに対処するために編集します。
コードを構築すると、プログラミングの設計と障害が特定されます。エクストリーム プログラミングは、テスト ベースが要件を保護するため、コードを気にせずに変更できるという利点があります。あなたの意図は良いものですが、現実には、コードとテスト ベースの構築を通じて設計上の問題や欠陥を発見すると、テスト テスト ケースをリファクタリング/再設計することになります。
ただし、私見では、非常に一般的なケースでは、コンパイルされないテストは事実上、先に進む前に修正する必要がある失敗しているメタ テストです。コードを書くように指示しています。
Wikipiedia からのモックの使用: モック オブジェクトは、制御された方法で実際のオブジェクトの動作を模倣するシミュレートされたオブジェクトです。プログラマーは通常、他のオブジェクトの動作をテストするためにモック オブジェクトを作成します。これは、自動車の設計者が衝突試験のダミーを使用して、車両の衝突時の人間の動的な動作をシミュレートするのとほぼ同じ方法です。
これを参照してください。
まだ存在しないオブジェクトのダイナミックを使用してこれを見つけました: https://coderwall.com/p/0uzmdw