テストされたクラスをスパイするのは悪い習慣ですか？

私はクラスの内部呼び出しが通常であるプロジェクトに取り組んでいますが、結果は何回も単純な値です。例（実際のコードではありません）：

public boolean findError(Set<Thing1> set1, Set<Thing2> set2) {
  if (!checkFirstCondition(set1, set2)) {
    return false;
  }
  if (!checkSecondCondition(set1, set2)) {
    return false;
  }
  return true;
}

このタイプのコードの単体テストを書くのは、実際の条件の実装ではなく、条件システムをテストするだけなので、非常に困難です。（私は別のテストでそれを行います。）実際、条件を実装する関数を渡した方が良いでしょうし、テストではモックを提供するだけです。このアプローチの問題は騒々しいです：ジェネリックを多く使用します。

実用的なソリューション。ただし、テスト対象のオブジェクトをスパイにし、内部関数の呼び出しを模擬することです。

systemUnderTest = Mockito.spy(systemUnderTest);
doReturn(true).when(systemUnderTest).checkFirstCondition(....);

ここでの懸念は、SUTの実装が効果的に変更されることであり、テストを実装と同期させておくことが問題になる場合があります。これは本当ですか？この内部メソッド呼び出しの混乱を避けるためのベストプラクティスはありますか？

アルゴリズムの一部について説明していることに注意してください。そのため、いくつかのクラスに分割することは望ましい決定ではない場合があります。

単体テストでは、テストするクラスをブラックボックスとして扱う必要があります。重要なのは、そのパブリックメソッドが期待どおりに動作することだけです。クラスが内部状態とプライベートメソッドを介してこれを達成する方法は重要ではありません。

この方法で意味のあるテストを作成することは不可能だと思うとき、それはあなたのクラスが強力すぎて、やりすぎだというサインです。これらの機能の一部を、個別にテストできる個別のクラスに移動することを検討する必要があります。

findError()およびcheckFirstCondition()などがクラスのパブリックメソッドである場合、findError()事実上、同じAPIからすでに利用可能な機能のファサードになります。これには何の問題もありませんが、既存のテストと非常によく似たテストを作成する必要があるということです。この複製は、単にパブリックインターフェイスの複製を反映しています。それは、この方法を他の方法と異なる方法で扱う理由ではありません。

単体テストは契約をテストする必要があります。彼らにとって唯一の重要なことです。契約の一部ではないものをテストすることは時間の無駄だけでなく、潜在的なエラーの原因です。開発者が実装の詳細を変更するときにテストを変更するのを見ると、アラームベルが鳴るはずです。その開発者は（意図的かどうかにかかわらず）彼の間違いを隠しているかもしれません。 実装の詳細を故意にテストすると、この悪い習慣が強制され、エラーがマスクされる可能性が高くなります。

内部呼び出しは実装の詳細であり、パフォーマンスの測定にのみ関心があります。これは通常、単体テストの仕事ではありません。

まず、あなたが書いた関数の例についてテストするのは難しいのだろうか？私が見る限り、さまざまな入力を渡して、正しいブール値が返されることを確認することができます。私は何が欠けていますか？

スパイに関しては、スパイとモックを使用するいわゆる「ホワイトボックス」テストは、書くべきテストコードが非常に多いだけでなく、実装が行われるたびに、書くのがはるかに多くの作業です変更した場合は、テストも変更する必要があります（インターフェイスが同じ場合でも）。また、この種のテストは、すべての追加テストコードが正しいことを確認する必要があるため、ブラックボックステストよりも信頼性が低く、ブラックボックスユニットテストがインターフェイスと一致しない場合に失敗することを信頼できます、テストではモックのみを使用して、実際のコードをあまりテストしないこともあるため、モックの過剰使用については信頼できません モックが正しくない場合、テストは成功する可能性が高いですが、コードはまだ壊れています。

ホワイトボックステストの経験がある人なら誰でも、書いて維持するのが大変だと言うことができます。信頼性が低いという事実と相まって、ホワイトボックステストはほとんどの場合、はるかに劣っています。