いくつかの理由で、プライベート機能のテストは好きではありません。それらは次のとおりです（これらはTLDRの人々にとって主要なポイントです）。
- 通常、クラスのプライベートメソッドをテストしたい場合、それはデザインの匂いです。
- パブリックインターフェイスを介してそれらをテストできます（クライアントがそれらを呼び出す/使用する方法であるため、テストする方法です）。プライベートメソッドのすべてのテストに合格すると、緑色の信号が表示され、安心感を得ることができます。パブリックインターフェイスを介してプライベート関数のエッジケースをテストする方がはるかに優れています。
- プライベートメソッドをテストすることで、テストが大幅に重複する可能性があります（外観が非常によく似たテスト）。要件が変化すると、必要以上のテストが失敗するため、これは大きな影響を及ぼします。また、テストスイートが原因でリファクタリングが困難な状況に置かれる可能性もあります。これは、テストスイートが安全に再設計およびリファクタリングを行うために存在するため、究極の皮肉です！
これらのそれぞれを具体的な例で説明します。2）と3）はやや複雑に関連していることがわかります。そのため、プライベートメソッドをテストしてはならない理由を個別に考えていますが、例は似ています。
プライベートメソッドのテストが適切な場合がありますが、上記のマイナス面に注意することが重要です。後で詳しく説明します。
最後に、TDDがプライベートメソッドをテストするための有効な言い訳にならない理由についても説明します。
悪い設計から抜け出す方法をリファクタリングする
私が目にする最も一般的な（反）パターンの1つは、Michael Feathersが"Iceberg"クラスと呼んでいるものです（Michael Feathersが誰であるかわからない場合は、彼の本「レガシーコードの効果的な使用」を購入/読んでください。彼はあなたがプロのソフトウェアエンジニア/開発者であるかどうかを知る価値のある人）。この問題を引き起こす他の（アンチ）パターンがありますが、これは私が偶然見つけた最も一般的なパターンです。「Iceberg」クラスには1つのパブリックメソッドがあり、残りはプライベートです（そのため、プライベートメソッドをテストしたくなります）。通常、1つのパブリックメソッドが出現するため、「Iceberg」クラスと呼ばれますが、残りの機能はプライベートメソッドの形で水中に隠されています。
たとえばGetNextToken()、文字列に対して連続的に呼び出し、期待した結果が返されることを確認してテストすることができます。このような関数はテストを保証します。特にトークン化ルールが複雑な場合、その動作は簡単ではありません。それほど複雑ではないと仮定してみましょう。スペースで区切られたトークンにロープをかけたいだけです。したがって、テストを作成すると、おそらく次のようになります（一部の言語にとらわれない擬似コード、うまくいけばアイデアは明確です）。
TEST_THAT(RuleEvaluator, canParseSpaceDelimtedTokens)
{
input_string = "1 2 test bar"
re = RuleEvaluator(input_string);
ASSERT re.GetNextToken() IS "1";
ASSERT re.GetNextToken() IS "2";
ASSERT re.GetNextToken() IS "test";
ASSERT re.GetNextToken() IS "bar";
ASSERT re.HasMoreTokens() IS FALSE;
}
まあ、それは実際にはかなりいいですね。変更を加えても、この動作を維持する必要があります。しかし、GetNextToken()ある民間の機能！このようにテストすることはできません。ためコンパイルすらため（Pythonなどの一部のスクリプト言語とは異なり、実際にパブリック/プライベートを強制する言語を使用していると仮定します）。しかしRuleEvaluator、単一の責任の原則（単一の責任の原則）に従うようにクラスを変更することについてはどうでしょうか？たとえば、パーサー、トークナイザー、エバリュエーターが1つのクラスに組み込まれているようです。それらの責任を分離する方が良いのではないでしょうか。その上、Tokenizerクラスを作成すると、そのパブリックメソッドはHasMoreTokens()andになりGetNextTokens()ます。RuleEvaluatorクラスが持っている可能性がありTokenizerメンバーとしてのオブジェクト。これで、上記の場合と同じテストを続けることができます。ただしTokenizer、RuleEvaluatorます。
UMLでは次のようになります。
この新しい設計によりモジュール性が向上するため、システムの他の部分でこれらのクラスを再利用できる可能性があることに注意してください（できなかった場合、プライベートメソッドは定義により再利用できません）。これは、RuleEvaluatorを分解する主な利点であり、理解度/局所性が向上します。
テストは非常に似ていますが、GetNextToken()メソッドがTokenizerクラスでパブリックになっているため、今回は実際にコンパイルされます。
TEST_THAT(Tokenizer, canParseSpaceDelimtedTokens)
{
input_string = "1 2 test bar"
tokenizer = Tokenizer(input_string);
ASSERT tokenizer.GetNextToken() IS "1";
ASSERT tokenizer.GetNextToken() IS "2";
ASSERT tokenizer.GetNextToken() IS "test";
ASSERT tokenizer.GetNextToken() IS "bar";
ASSERT tokenizer.HasMoreTokens() IS FALSE;
}
パブリックインターフェイスを介してプライベートコンポーネントをテストし、テストの重複を回避する
問題をより少ないモジュール式コンポーネントに分解できるとは思わない場合でも（それを行おうとするだけで95％の確率で実行できます）、パブリックインターフェイスを介してプライベート関数をテストできます。多くの場合、プライベートメンバーはパブリックインターフェイスを通じてテストされるため、テストする価値はありません。私が目にするのは非常によく見えるテスト、よく似たテストですが、2つの異なる関数/メソッドをテストします。何が起こって終わることは要件の変更が（と彼らはいつも）とき、あなたは今の代わりに1の2つの壊れたテストを持っているそして、あなたは本当にすべてのあなたのプライベートメソッドをテストした場合、あなたはより多くのような10回の壊れたテストの代わりの1持っているかもしれないということです要するにを、プライベート関数のテスト（FRIEND_TESTまたは、パブリックにするか、リフレクションを使用して）、パブリックインターフェイスを介してテストしないと、テストが重複する可能性がありますリフレクションのたりすると、通常、最終的にはそれを後悔することになります。。あなたが本当にこれを望まないのは、あなたのテストスイートがあなたを遅くすること以外に害を与えるものはないからです。開発時間を短縮し、メンテナンスコストを削減するはずです。パブリックインターフェイスを介して他の方法でテストされるプライベートメソッドをテストする場合、テストスイートは反対のことを非常にうまく行い、メンテナンスコストを増加させ、開発時間を増加させます。プライベート関数をパブリックにする場合、または次のようなものを使用する場合FRIEND_TEST
Tokenizerクラスの次の可能な実装を検討してください。
SplitUpByDelimiter()配列の各要素がトークンになるような配列を返す責任があるとしましょう。さらに、それGetNextToken()は単にこのベクトルの反復子であるとしましょう。したがって、公開テストは次のようになります。
TEST_THAT(Tokenizer, canParseSpaceDelimtedTokens)
{
input_string = "1 2 test bar"
tokenizer = Tokenizer(input_string);
ASSERT tokenizer.GetNextToken() IS "1";
ASSERT tokenizer.GetNextToken() IS "2";
ASSERT tokenizer.GetNextToken() IS "test";
ASSERT tokenizer.GetNextToken() IS "bar";
ASSERT tokenizer.HasMoreTokens() IS false;
}
Michael Featherが模索ツールと呼んでいるものがあるとしましょう。これは、他の人のプライベートな部分に触れることができるツールです。例はFRIEND_TESTgoogletest、または言語がそれをサポートする場合のリフレクションからです。
TEST_THAT(TokenizerTest, canGenerateSpaceDelimtedTokens)
{
input_string = "1 2 test bar"
tokenizer = Tokenizer(input_string);
result_array = tokenizer.SplitUpByDelimiter(" ");
ASSERT result.size() IS 4;
ASSERT result[0] IS "1";
ASSERT result[1] IS "2";
ASSERT result[2] IS "test";
ASSERT result[3] IS "bar";
}
さて、要件が変更され、トークン化がさらに複雑になったとしましょう。単純な文字列区切り記号では不十分であると判断し、必要なDelimiter、ジョブを処理クラス。当然、1つのテストが失敗することを期待することになりますが、プライベート関数をテストすると、その痛みが増大します。
プライベートメソッドのテストが適切なのはいつですか？
ソフトウェアには「1つのサイズですべてに対応」することはできません。時々「ルールを破る」ことは大丈夫です（そして実際には理想的です）。できる限りプライベート機能をテストしないことを強くお勧めします。大丈夫だと思う主な状況は2つあります。
私はレガシーシステムを広範囲にわたって使用してきました（そのため、私はMichael Feathersの大ファンです）、プライベート機能をテストするのが最も安全な場合もあると言えます。「特性評価テスト」をベースラインに入れるのに特に役立ちます。
あなたは急いでいて、今ここで可能な限り最速のことをしなければなりません。長期的には、プライベートメソッドをテストする必要はありません。ただし、設計の問題に対処するために通常はリファクタリングに時間がかかると言います。そして、時にはあなたは一週間で出荷する必要があります。それは大丈夫です：あなたがそれがあなたが仕事を成し遂げるための最も速くて最も信頼できる方法であると思うなら、手探りツールを使用してプライベートメソッドをすばやくそして汚いようにテストしてください。しかし、あなたがしたことは長期的には次善の策であったことを理解し、それに戻ることを検討してください（または、それが忘れられたが後で見た場合は修正してください）。
おそらく他の状況でも問題ないでしょう。大丈夫だと思い、正当な理由がある場合は、それを実行してください。誰もあなたを止めません。潜在的なコストに注意してください。
TDDの言い訳
余談ですが、私はTDDをプライベートメソッドのテストの言い訳として使用することを本当に嫌いです。私はTDDを実践していますが、TDDがこれを強制することはないと思います。最初に（パブリックインターフェイス用の）テストを記述してから、そのインターフェイスを満たすコードを記述できます。ときどき、パブリックインターフェイスのテストを作成し、1つまたは2つの小さなプライベートメソッドも作成してそれを満たします（ただし、プライベートメソッドを直接テストしませんが、動作することはわかっています。または、パブリックテストが失敗します。 ）。そのプライベートメソッドのエッジケースをテストする必要がある場合は、パブリックインターフェイスを介してヒットする一連のテスト全体を記述します。エッジケースにヒットする方法がわからない場合、これは、それぞれが独自のパブリックメソッドを持つ小さなコンポーネントにリファクタリングする必要があることを示す強い兆候です。これは、プライベート関数がやりすぎであり、クラスのスコープ外であることを示しています。
また、時々、私が現時点で噛むには大きすぎるテストを書いていることに気づくことがあります。コメントアウトして、私の心の奥に留めておきます）。ここで、私が会った多くの開発者がTDDをスケープゴートとして使用して、プライベート機能のテストを作成し始めます。「ああ、まあ、他のテストが必要ですが、そのテストを書くには、これらのプライベートメソッドが必要になります。したがって、テストを書かないとプロダクションコードを書くことができないので、テストを書く必要があります。プライベートメソッドの場合。」しかし、彼らが実際に行う必要があるのは、現在のクラスにプライベートメソッドの束を追加/テストする代わりに、小さくて再利用可能なコンポーネントにリファクタリングすることです。
注意：
少し前に、GoogleTestを使用したプライベートメソッドのテストに関する同様の質問に回答しました。ここでは、その答えをより言語にとらわれないように変更しました。
PSこれは、Michael Feathersによる氷山のクラスと模索ツールに関する関連する講義です。https：//www.youtube.com/watch？v = 4cVZvoFGJTU