皆さん、TDD では常に次のように言われています。
実際のコードを記述する前に、junit を記述する必要があります。
どういうわけか、私はこれを正しい精神で理解することができません。それが意味することは、正しい署名で空のメソッドを書くだけで、テストケースが最初に失敗すると予想されることです
TDD アプローチでは、顧客のリストを取得する必要があるとします。
私の理解では、以下のように空のメソッドを書きます
public List<CustomerData> getCustomers(int custId){
return null;
}
ここで、サイズが 10 であることを確認する Junit テスト ケースを作成します (実際に期待しています)。これは正しいですか？
基本的に私の質問はTDDにあります。実際のコードを書く前にjunitテストケースを書くにはどうすればよいですか?
多くの場合、コードのスケルトンと一緒にテストを記述します。最初に、機能しない実装 (たとえば、 throw UnsupportedOperationException) を作成すると、テストの失敗がトリガーされます。次に、最終的にテストに合格するまで、実装を具体化します。
これについては現実的になる必要があります。明らかに、少なくともテスト対象のユニットがコンパイルされるまでテストをコンパイルできないため、テストと並行して最小限の実装作業を行う必要があります。
この最近の Dr. Dobbs の社説をチェックしてください。これは、特にこの実践の達人 (Kent Beck et al )によって、まさにこの点と、これに関するプラグマティズムの役割について説明しています。
TDD の重要な原則は、最初に失敗する単体テストを作成しない限り、コードを作成しないということです。しかし実際には、TDD の主要な支持者 (この手法を普及させた Kent Beck や、何千人もの開発者に TDD を教えてきた Bob Martin など) と話をすると、どちらもテストを書かずにコードを書いていることがわかります。最初。彼らは、これを強調しておきますが、これらの瞬間を信頼の失墜とは見なさず、むしろ知的な開発者に必要なプラグマティズムと見なします。
それが意味することは、正しい署名で空のメソッドを書くだけであることを願っています
はい。また、最近のほとんどの IDE では、テストに存在しないメソッド名を記述すると、スタブが作成されます。
TDD アプローチでは、顧客のリストを取得する必要があるとします。進むべき正しい方法は何ですか？
あなたの例はそれほどではありません。長さ 0 の配列をテストしたいのですが、既にそれを返しています。最初に を返す必要がありますnull。テストは明らかに失敗します。
次に、テストが成功するようにメソッドを変更します。
次に、顧客追加用のテスト メソッドを作成します。テストは失敗します。修理する。リンス。繰り返す。
したがって、基本的には、TDD を使用すると、失敗することがわかっているテストを開始して記述し、コードが機能するように修正します。
それは部分的に正しいです。
IDE (Eclipse、IntelliJ) を使用して、テストを作成できます。そのテストでは、(存在しない) メソッドを呼び出し、リファクタリング ツールを使用して、適切なシグネチャを持つメソッドを作成します。
これは、TDD での作業をより簡単に、より楽しくするためのトリックです。
あなたによると、適切な実装を提供するNow i will write junit test case where i will check the size as 0. Is this Right?テストを書く必要があります。fails