TDDを使用するには、テスト中のメソッドのシグネチャを変更する必要がありますか？

Question

私はTDD方法論の周りに頭を上げようとしています。私が思うには、鶏と卵の問題：バグ修正でメソッドの署名が変更された場合の対処方法

は、以下のメソッドシグネチャを検討：名前が示唆するよう

string RemoveTokenFromString (string delimited, string token) 

、この方法はdelimitedからtokenのすべてのインスタンスを除去し、得られた文字列を返します。

このメソッドにはバグがあります（たとえば、不適切なビットが文字列から削除されているなど）。そこで、バグが発生するシナリオを記述するテストケースを作成し、テストが失敗することを確認します。

このバグを修正すると、メソッドはジョブを正常に実行するためにはより多くの情報が必要であることがわかりました。この情報ビットはパラメータとしてのみ送信できます（テスト対象のメソッドは静的クラスの一部です）。

私は何をしますか？私がバグを修正すると、これは私にユニットテストを変更するよう強要します - それは「正しい」TDD方法論でしょうか？

Answer 1

ユニットの意図された動作が変化したことを発見したとき、テストを爆破することには何も問題はありません。

//Up front 
[Test] 
public void should_remove_correct_token_from_string() 
{ 
    var text = "do.it.correctly.."; 
    var expected = "doitcorrectly"; 
    Assert.AreEqual(StaticClass.RemoveTokenFromString(text, "."), expected); 
} 

//After finding that it doesn't do the right thing 
//Delete the old test and *design* a new function that 
//Does what you want through a new test 
//Remember TDD is about design, not testing! 
[Test] 
public void should_remove_correct_token_from_string() 
{ 
    var text = "do.it.correctly.."; 
    var expected = "doitcorrectly"; 
    Assert.AreEqual(
     StaticClass.RemoveTokenFromString(
      text, 
      ".", 
      System.Text.Encoding.UTF8), expected); 
} 

//This will force you to add a new parameter to your function 
//Obviously now, there are edge cases to deal with your new parameter etc. 
//So more test are required to further design your new function 

Answer 2

赤、緑、リファクタリング。

あなたは何をしても、まずバグを再現するコンパイルされているが失敗したテストケースがある状態になりたいと思う。次に、テストと実装にパラメータを追加するだけで、何も実行しないので、まだ赤があります。

Answer 3

メソッドが正しくジョブを実行していない場合は、修正が必要であり、修正が署名の変更を必要とする場合は、間違っていることに注意してください。 TDDによると、最初にテストケースを作成します。これは確実に失敗します。テストを満たすメソッドを作成します。このアプローチでは、メソッド呼び出しで関数を呼び出すためにパラメータが必要な場合は、関数を呼び出す必要があります。

Answer 4

はここに助けることができるAdd Parameter呼ばリファクタリングがあります。

ご使用の言語がmethod overloadingをサポートしている場合は、新しいパラメータを使用して新しい関数を作成し、既存の関数の本体をコピーして問題を修正することができます。

問題が修正されたら、すべてのテストを1つずつ変更して新しいメソッドを呼び出すことができます。最後に、古いメソッドを削除できます。

メソッドのオーバーロードをサポートしない言語では、別の名前の新しい関数を作成し、その新しい関数の既存の関数に本体をコピーし、新しい関数を呼び出す既存の関数を新しいパラメータそれから、すべてのテストを通過させることができます。あなたの古いテストが新しい機能を1つ1つ呼び出すようにします。古いメソッドがもう使用されないと、それは削除され、新しい関数の名前が変更されます。

これはちょっとプロセスが広がっていますが、これはがの赤緑色のリファクタに続くTDD方法だと思います。

パラメータのデフォルト値もあります（使用可能な場合）。

Answer 5

簡単にしてください。

ユニットテストが間違っているか、または廃止された場合は、それを書き直す必要があります。スペックが変更された場合、または特定のスペックがもはや関連性がない場合、ユニットテストはそれを反映する必要があります。

赤、緑、リファクターは、テストしているコードだけでなく、単体テストにも適用されます。

Answer 6

「正しい」/「正しい」方法については言わないでください...ソリューションにもっと近づけるのに役立ちます。テストケース

で

あなたは追加のパラメータに取る必要があることが判明した場合、

• 更新呼び出しは、実際の方法
• に新しいパラメータを追加するには、コードのビルドことを確認し、テストは再び失敗します。
• これを緑色にします。

新しいパラメータを追加するとコンパイルエラーが発生する場合がありますが、私はお勧めしますか？ベイビーステップで...ソースベース全体を更新する前に、 3番目のパラメータが必要です。または4番目のパラメータが必要です。時間が失われました。したがって、すべての参照を更新する前に、新しいバージョンのメソッド 'working'を取得してください。 （フィリップはここで言うように）

• は追加パラメータ
との新しいオーバーロードがいくつかで新しい過負荷に古い過負荷リレーまたはデリゲートを作成し、新たな過負荷
• に古いメソッドのコードを移動し
• 書きます新しいパラメータのデフォルト値
• これで手元にあるタスクに戻り、新しいテストを緑色にすることができます。
• 古いオーバーロードがもう必要ない場合は、それを削除して、結果として生じるコンパイルエラーを修正してください。

Answer 7

あなたはTDDで最も危険な罠に陥っています.TDDはテストに関するものだと思いますが、そうではありません。しかし、TDDのすべての用語はテストに関するものなので、そのトラップに入るのは簡単です。これがBDDが発明された理由です。基本的にはTDDですが、混乱する用語はありません。

TDDでは、テストは実際のテストではなく、例です。アサーションは本当にアサーションではなく、期待通りです。あなたはユニットを扱っていない、あなたは行動を扱っている。 BDDはそれを単にそれらと呼んでいます。 （注：BDDは最初に発明されて以来進化しており、現在はTDDの一部ではないものが組み込まれていますが、当初の意図は「多くの人がTDDを間違えているので、 ）

とにかく、テストではなく、メソッドがどのように動作するべきかの動作例を考えるなら、期待される動作をより深く理解するように、テストを削除または変更するTDDだけでなく、唯一の正しい選択です！常に心に留めておいてください！