メソッドがTDDで再設計されてプライベートになった場合、メソッドのテストはどうなりますか？

他のキャラクターやそのようなものを攻撃するキャラクターでロールゲームの開発を始めたとしましょう。

TDDを適用して、Character.receiveAttack(Int)メソッド内のロジックをテストするテストケースを作成します。このようなもの：

@Test
fun healthIsReducedWhenCharacterIsAttacked() {
    val c = Character(100) //arg is the health
    c.receiveAttack(50) //arg is the suffered attack damage
    assertThat(c.health, is(50));
}

メソッドをテストreceiveAttackする10のメソッドがあるとします。次に、メソッドCharacter.attack(Character)（メソッドを呼び出すreceiveAttack）を追加し、TDDサイクルでテストした後、決定するCharacter.receiveAttack(Int)必要がありますprivate。

以前の10個のテストケースはどうなりますか？それらを削除する必要がありますか？メソッドを保持する必要publicがあります（そうは思わない）。

この質問は、プライベートメソッドをテストする方法ではなく、TDDを適用する際の再設計後にそれらを処理する方法に関するものです。

TDDでは、テストは設計の実行可能なドキュメントとして機能します。デザインが変更されたので、明らかにドキュメントも必要です！

TDDでは、attackメソッドが表示される唯一の方法は、失敗したテストパスの結果であることに注意してください。つまり、attack他のテストによってテストされています。これは、間接的に のテストでreceiveAttackカバーされることを意味しattackます。理想的には、への変更receiveAttackはattackのテストの少なくとも1つに違反するはずです。

そして、もしそうでなければ、receiveAttackその機能はもはや必要ではなく、もはや存在すべきではありません！

ですから、receiveAttackは既にでテストされているattackため、テストを保持するかどうかは関係ありません。場合は、あなたのテストフレームワークを作ることは簡単でプライベートメソッドをテストするために、そして場合あなたはプライベートメソッドをテストすることを決定し、その後、あなたはそれらを維持することができます。ただし、テストの範囲と信頼性を失うことなく削除することもできます。

メソッドがテストを必要とするほど複雑な場合は、何らかのクラスでパブリックにする必要があります。だからあなたはからリファクタリングします：

public class X {
  private int complexity(...) {
    ...
  }
  public void somethingElse() {
    int c = complexity(...);
  }
}

に：

public class Complexity {
  public int calculate(...) {
    ...
  }
}

public class X {
  private Complexity complexity;
  public X(Complexity complexity) { // dependency injection happiness
    this.complexity = complexity;
  }

  public void something() {
    int c = complexity.calculate(...);
  }
}

X.complexityの現在のテストをComplexityTestに移動します。次に、複雑さをあざけることによってX.somethingにテキストを送信します。

私の経験では、より小さなクラスとより短いメソッドにリファクタリングすることは大きな利点をもたらします。理解しやすく、テストしやすく、最終的には予想以上に再利用されます。

receiveAttackメソッドをテストする10のメソッドがあるとします。次に、Character.attack（Character）メソッド（receiveAttackメソッドを呼び出す）を追加し、TDDサイクルでテストした後、Character.receiveAttack（Int）をプライベートにする必要があります。

ここで心に留めておくべきことは、あなたが下している決定は、APIからメソッドを削除することであるということです。後方互換性のおかげで、

1. 削除する必要がない場合は、APIに残します
2. 削除する必要がない場合 まだ、非推奨としてマークし、可能であれば、寿命の終わりが来たときに文書化してください
3. 削除する必要がある場合は、メジャーバージョンが変更されています。

APIがメソッドをサポートしなくなると、テストは削除または置換されます。その時点で、privateメソッドは実装の詳細であり、リファクタリングできるようにする必要があります。

その時点で、テストスイートが純粋にパブリックAPIを介して対話するのではなく、実装に直接アクセスする必要があるかどうかという標準的な質問に戻ります。プライベートメソッドは、テストスイートが邪魔になることなく置き換えることができるものです。そのため、それに結合するテストがなくなることを期待します-廃止されるか、実装とともに個別にテスト可能なコンポーネントに移行します。