唯一のロジックがガードである単体テストメソッドは便利ですか？

次のような方法があるとします。

public void OrderNewWidget(Widget widget)
{
   if ((widget.PartNumber > 0) && (widget.PartAvailable))
   {
        WigdetOrderingService.OrderNewWidgetAsync(widget.PartNumber);
   }
}

私のコードにはそのようなメソッドがいくつかあります（非同期Webサービス呼び出しの前半分）。

それらを単体テストでカバーすることが有用かどうかを議論しています。はい、ここにはロジックがありますが、それはガードロジックにすぎません。（つまり、Webサービスの呼び出しを許可する前に、必要なものがあることを確認します。）

私の一部は、「あなたはそれらをユニットテストできることを確認しますが、それは時間の価値がありません」と言います（私はすでに予定より遅れているプロジェクトにいます）。

しかし、私の反対側は、もしあなたがそれらを単体テストしないで、誰かが衛兵を変えれば、問題があるかもしれないと言います。

しかし、私の最初の部分は、誰かがガードを変更した場合、あなたは彼らのためにもっと仕事をしているだけだと言います（ガードとガードのユニットテストを変更しなければならないからです）。

たとえば、私のサービスがウィジェットの可用性をチェックする責任を負う場合、そのガードをこれ以上望まないかもしれません。単体テスト中の場合は、2つの場所を変更する必要があります。

私は両方の面で賛否両論を見ています。だから私は他の人が何をしたかを尋ねると思った。

私の一部は、「あなたはそれらをユニットテストできることを確認しますが、それは時間の価値がありません」と言います（私はすでに予定より遅れているプロジェクトにいます）。

非常に短い3つのテストです。あなたは自分自身に質問するのに多くの時間を費やしました。

しかし、私の反対側は、もしあなたがそれらを単体テストしないで、誰かが衛兵を変えれば、問題があるかもしれないと言います。

こちら側を聞いてください。

しかし、私の最初の部分は、誰かがガードを変更した場合、あなたは彼らのためにもっと仕事をしているだけだと言います（ガードとガードのユニットテストを変更しなければならないからです）。

あなたのメンテナーがTDDナッツであるなら、あなたはそれらをより難しくしている。関連する変更やテストの追加がなくても変更を加えると、一生懸命考えなければなりません。実際、テストを追加してから変更を加えます。

あなたの最初の部分は明らかに間違っています。2番目の部分の背面を軽くたたいて、それについて考えるのを止めます。

ガードロジックと実際の順序付けが別々の方法である場合、単体テストが簡素化されます。

ではWidgetクラス

public bool IsReadyForOrdering { get { return PartNumber > 0 && PartAvailable; } }

または同等のメソッドをどこかに

public bool IsWidgetReadyForOrdering(Widget widget)
{
    return widget.PartNumber > 0 && widget.PartAvailable;
}

注文方法

public void OrderNewWidget(Widget widget)
{
   if (IsWidgetReadyForOrdering(widget)) {
        WigdetOrderingService.OrderNewWidgetAsync(widget.PartNumber);
   }
}

テストIsWidgetReadyForOrderingが簡単になりました。もう長い間考えないでください。試して！

単体テストのスケジュールに時間がないが、しっかりしたQAの使用に時間を割くことができる場合、そのQA時間の一部を盗んで単体テストを書くことができるかどうか、またはQA期間の一部を費やすことができるかどうかを尋ねますユニットテストを実行するか、ユニットテストされていないコードを処理します。残念ながら、不動のスケジュールは譲歩するか、自分自身を死に至らしめることを余儀なくされます。その期間システムを正しく維持する。

とはいえ、ガードステートメントをテストするという一般的な質問には、はい！ガードステートメントを絶対にテストしてください！これらは、そのメソッドの動作の重要な部分であり、あなたはバグ修正をしている誰かの誤解何かを知りたいと、あなたのガードを削除または変更していないだろう&&に||、あなたでしょうか？ユニットテストは、a）実際にガードのロジックを正しく取得し、b）何らかの理由でユニットテストを実行するように指示するユニットテストを実行するときに、文句を言わずに後で誰もそのロジックを壊さないことを確認します。

上記のいくつかの優れた回答がありますが、それらのポイントは非常に重要です。しかし、見逃されているように見えるのは、あなたが包括的なユニットテストのセットを持っているということです。彼らはコードの非常に詳細な仕様のように読みます。コードが非常に簡単であるために検証のテストを省略すると、コードがどのように間違っているかを確認するのが難しいため、仕様の一部が欠落しています。これらのテストが見落とされていたチームに入った場合、実際にはあなたのサービスがその引数を検証していないと思います。

コードはコードです。テストするときは、100％のカバレッジを得るようにしてください。それが重要でなければ、そこにはないでしょう。