私は初心者のプログラマーですが、単体テスト用に適切に構成されたアプリケーションを作成する方法がわかりません。後で効果的な単体テストを追加できるアプリケーションを作成したいと考えています。
問題はprivate
メソッドにあります-それらはクラス外でテストすることはできません。
private
であるすべてのメソッドをprotected
に変更してこの問題を解決し、テストクラスにソースクラスを拡張させますか?または、より良い解決策はありますか?
私のソリューション(プライベートsplitLetters =>保護されたsplitLetters)は次のように機能します。
ソースクラス:
class MyClass{
protected splitLetters(int num){
return num+2;
}
}
テストクラス:
class Test_MyClass extend MyClass{
public splitLettersTest(){
for(int i=0;i<100;i++){
System.println(parent.splitLetters(i));
}
}
}
ソリューション:
プライベートメソッドをテストしない-プライベートメソッドが非常に複雑なタスクを実行しているため、十分にテストする必要があり、ユーザーがアクセスできないようにする必要があるこのメソッドに。まもなく、ソリューションはプライベートメソッドを保護されたものに変更します。
ネストされたクラスのテスト方法-QAがソースコードを変更するため問題
Reflection-これがプライベートメソッドの呼び出しを可能にする場合、それは素晴らしいソリューションのように見えます http://www.artima.com/ suiterunner/private3.html (リフレクションを理解するためにもっと学ぶ必要があります。別のクラスからプライベートメソッドを呼び出すことができる場合、リフレクションがパブリックメソッドとプライベートメソッドを持つという考えをすべて損なうわけではありません。)
プライベートメソッドを定義しない(ソリューションで示したように)-プライベートメソッドを定義する必要がある場合があるため、問題があります。
プライベートメソッドをテストする必要はありません。
プライベートメソッドのテストは、機能ではなく実装のテストを意味します。 whyについて非常に慎重に検討してください。プライベートメソッドをテストしたいのですが、それらをまったくテストする必要がない場合があります。
私の個人的な見解では、(可能な限り)その機能のエンドユーザーに公開されている動作のみをテストする必要があるため、プライベートメソッドはテストしないでください。
このテストは、内部機能の一部が実際にソフトウェアを使用している人々にとって意味のない何かに従って「機能している」ことを示すことを除いて、何も証明しません。
内部実装を変更またはリファクタリングすると、実際に公開されている外部機能がまったく変更されていないのに、ユニットテストが失敗し始めることがあります。
もちろん、大きなプロジェクトを機能の小さなチャンクに分割することを選択することもできます。その場合、インターフェイス間のインターフェイスを単体テストすることを選択できます(たとえば、DAL実装はエンドユーザーに直接影響しません)。
プライベートメソッドをテストする必要はありません。パブリックメソッドをテストする場合、理論上はプライベートメソッドもテストする必要があります。