3

これは私たちが何度も議論してきたことであり、人々の意見はこれについてかなり異なっているようです.

TDD を実行するときの基本的な質問は、サイクルのリファクタリング ステップの後に追加の単体テストを追加する必要があるかどうかです。次のサイクルを開始するための次のテストについて話しているのではなく、リファクタリングによって生じた変更をカバーするためのテストです。

これは、実際の例で説明するのが一番かもしれません。TDD サイクルのグリーンの後、次のコードが得られます。

    public bool ShouldVerifyDomain
    {
        get
        {
            return this.Orders.SelectMany(x => x.Items).Any(x => x.Product.RequiresDomainVerification);
        }
    }

さて、私はこれを見て、うーん、linq ステートメントはもう少し整頓されていて、もう少し読みやすく、Demeter にそれほど違反していないのではないかと思います。それをリファクタリングしましょう。だから私は次のように作成しますOrder：

 public bool HasItemsThatRequireDomainVerification
 {
     get
     {
          return this.Items.Any(x => x.Product.RequiresCascadeDomainVerification);
     }
 }

そして次のように変更されShouldVerifyDomainました：

  public bool ShouldVerifyDomain
  {
      get
      {
           return this.Orders.Any(x => x.HasItemsThatRequireDomainVerification);
      }
  }

OK、それは少し良くなっているように見えます。私はそれで満足しています。私のリストの次のテストに移りましょう...しかし...待ってください、私たちは今HasItemsThatRequireDomainVerification別のオブジェクトのプロパティを介してプロパティをテストしています....それは本当の単体テストですか、それともテストを追加する必要がありますか? ) を直接テストしHasItemsThatRequireDomainVerificationます。

私が感じる方法？それが大きな付加価値になるとは思えません。スイートのメンテナンスの負担が増し、時間がかかり、将来の変更に関して自信が持てなくなると思います。

それは私たちに何を与えるでしょうか？のパブリック インターフェイスの「ドキュメント」Order。

考え？

4

3 に答える 3

4

TDD を行っている場合、テストは機能性「機能テスト」のレベルにある必要があるため、機能性が変わらない限り、テストを変更しないでください。

実装の変更またはリファクタリングは、機能の入力と出力が同じである限り、TDD の詳細と見なされます。

TDD によって 100% のカバレッジが得られるわけではありません。

一方、単体テストをコードの説明として使用している場合、または 100% のカバレッジが必要な場合 (コードの 1 つの部分のみを対象とする必要があるため、ここでは単体テストについて話しています)、それらの単体テストは毎回変更する必要があります。実装はすべてのケースをカバーするように調整されていますが、これは TDD の目標ではありません。

于 2013-07-16T14:36:13.753 に答える
2

動作は変更されておらず、構文のみが変更されています。コードは同じように機能しますが、書き方が異なるだけです。同じように機能する限り、単体テストの信頼性は保たれると思います。

リファクタリングによって、リファクタリングした新しいコードのテストを開始する必要がある場合、最終的にはうさぎの穴に落ちてしまうと思います。いつ終わるの？

于 2013-07-16T14:38:43.557 に答える