TDD、何もプライベートメソッドを使用しない場合、2つのパブリックメソッドをテストする方法は？

Question

同様の引数を持つプライベートメソッドを1つしか使用しない場合、2つのメソッドをテストする必要がありますか？例えば

私はいくつかのインタフェース（契約）があります。このインタフェースの

public interface IInterface 
{ 
    void Method1(arg1, arg2, arg3); 
    void Method2(arg1, arg2, arg3); 
} 

と実装：たとえば

public class MyClass : IInterface 
{ 
    public void Method1(arg1, arg2, arg3) 
    { 
     Method3(arg1, arg2, arg3) 
    } 

    public void Method2(arg1, arg2, arg3) 
    { 
     Method3(arg1, arg2, arg3) 
    } 

    private void Method3(arg1, arg2, arg3) 
    { 
     // handle data 
    } 
} 

私はmethod1には3つのテストを持っている、それがペーストをコピーするために必要ですこれはTDD/RGBルールに基づくMethod2のテストです

Answer 1

のために行くだろうだから、聞こえます。これを使用している場所が広く普及している場合や、リファクタリングすることができない共有コードベースであれば、それは妥当かもしれません。

私はこのクラスをより洗練されたインターフェースのファサードに変えることができます。つまり、プライベートメソッドを簡潔なインターフェイスで新しいクラスに引き出します。次に、既存のクラスと同じように既存のクラスを使用しますが、実際の実装に依存します。

これは利点のカップルを持っている：

1. あなたは徐々に新しい実装に元のインターフェースに依存するクラスの移動を開始することができます。 （特に、これらの方法を他の開発者に警告するために非難する場合）。最終的に、ファサードは完全に削除することができます。
2. 新しいクラスを幅広くユニットテストすることができます。
3. 2つの非常に簡単な単体テストを作成して、既存のクラスでこの依存関係を呼び出していることを確認できます。

Answer 2

TDD/RGBルールに基づいてMethod2のこのテストをコピー貼り付けする必要がありますか

は少し強すぎます。 TDD警察はあなたのドアを蹴ってくることはありません。

しかし、あなたは確かにラインの外側に着色しています。

MyClass.Method2が本当にすべての面白いケースでMyClass.Method1と同じ振る舞いをすると想定されている場合は、このプロパティを記録するテストを行う必要があります。

このテストは、既存のテストのコピー貼り付けである必要はありません。それはデータ駆動テストのようなものかもしれません。

[TestMethod()] 
public void testMethodEquivalence() { 
    val arg1 = TestContext.DataRow["arg1"] 
    val arg2 = TestContext.DataRow["arg2"] 
    val arg3 = TestContext.DataRow["arg3"] 

    MyClass expected = new MyClass(); 
    MyClass sut = new MyClass(); 

    Assume.That(sut, Is.EqualTo(expected)) 

    expected.Method1(arg1, arg2, arg3) 
    sut.Method2(arg1, arg2, arg3) 

    Assert.That(sut, Is.EqualTo(expected)) 
} 

ポイントは、どこかで、変更のいずれかのクラスの契約に違反した場合、新鮮なコーダのリファクタリングが容赦なく警告されることをMyClass.Method2の実施に十分な制約がなければならないということです。ユニットテストの

Answer 3

コア点は、テスト対象のコードの公共契約を確認にあります。

この意味では、最初の観察は次のようになります。あなたの例では、両方のメソッドが全く同じ引数をとり、まったく同じことを行います。合理的な答えは： Method1とMethod2が必要です - あなたはMethod3をpublicにして呼び出します。集中

は、方法1に焦点を当てた、といくつかのテストを「OK、それが動作」を有する両方のパブリックメソッドをテスト

• ：あなたの例は、過簡素化され、あなたが本当に2つのの選択肢を持っていると仮定すると

  方法2

のために何の黄金のルールがここにはありません - あなたは、バックステップとどのようにそうそれはあなたの実装のwiこと例えばある決めなければなりませんいつも変わるでしょう。しかし、その場合は、TDDをやっているでしょう。つまり、Method2を変更した場合は、最初にのテストをチェックアウトします。そして、あなたがであるときにが十分でないことがわかったとき - あなたはもっと多くのものを加えることができます。あなたが本当に1つの単純化されたインタフェースを使用するように、クラスの呼び出し元をリファクタリング行きたくないようにそこから来る

、私はオプション2