ユニットテストベストプラクティス
3379 ワード
ユニットテストは開発を駆動し,設計を再構築し,コード品質を向上させるために,テストカバー率を無駄に追求することはできず,テストが困難なシーンに対しては,各項目要因(投入/産出)に応じて適切な剪断が必要である.動作をテストし、方法 ではありません.
複数のメソッドは1つの動作を構成する可能性があり、1つのメソッドは複数の動作を含む可能性があり、1つのメソッドが複数の用途に使用できる場合、パラメータによって異なる表現がある可能性があります.各表現は1つの動作であり、複数のメソッドが1つの行を構成する場合があります.付随するメソッドは、メインメソッドでのみ使用され、メインメソッドのみをテストできます.
プライベートメソッドをテストする必要があるかどうか:
プライベートメソッドは一般的にテストが容易ではなく、複雑ではないプライベートメソッドに対しては、必然的に他の公有メソッドに呼び出されるため、一般的にテストを行わなくてもよい.プライベートメソッドが複雑であるか、開示されたメソッドで全面的にテストするのが難しい場合は、反射を使用してテストすることができます.
2.「Too Simple to Break」ルールの使用
テストセットで高いコードオーバーライド率を維持することは重要であるが、100%のオーバーライド率を獲得することは賢明ではない.収益の減少の観点を考慮しなければならない.良い経験は、1つの方法が分割できないほど簡単であれば、ユニットテストを書く必要はありません.「分割できないほど簡単」とは説明にもよるが、次の方法でユニットテストを書くのは役に立たない.
public String getName() {
return name;
}
簡単なアクセス方法のテストは望ましくない.
テスト作業は非常に時間のかかる作業であり、将来の時間を節約します.そのため、テストが有効であることを確認してください.良いテストは、モジュールごとにコア機能をテストするのではなく、細かくテストする必要があります.ソフトウェアシステムの動作に対してテストコードを記述する必要があります.あなたはすべてを必要としません.今考えているもののためにまずテストを作成し、それから他のことを考えてからもっとテストを増やします. 試験例においてオブジェクト向けベストプラクティス を用いる.
テスト用例を先頭などのコード資産を整理することが重要です.製品コードを書くのと同じデザインを使ってテスト例を書くべきです.これは、テスト例を再構築したり、汎用機能をベースクラスにアップグレードしたり、重複コードを削除したり、長い方法を分解したりする機会を探すことを意味します.これができないと変更の費用がかかり、時間が経つにつれてテストセットが無効になるという観点で説明する必要があることは、プロジェクトの実際の状況によって異なり、時間が短いプロジェクトでは、ユニットテストで大量のコピーが貼り付けられ、冗長コードが受け入れられる. 適切な方法名 を用いる.
これは明らかに見えますが、次のようなテスト方法がよく見られます.
代わりに、テストの目的を明確に記述できる方法名を使用する必要があります.このようにすると、あなたのテスト例がよりよく理解され、メンテナンスされやすくなります.例: Try/Catchブロックを使用する予期しない異常 を捕捉しないでください.
肉眼検査 に頼らないでください.
テストの成功または失敗は、開発者がコンソールを目視して結果を決定することに基づいてはならない.これはシステムを使うべきではないことを意味します.out.println()またはLogger.debug()文は、あなたのテストの成功状態を決定します.代わりに、JUnitの様々なassertXXX()メソッドに依存する必要があります.そのため、テストは無人の世話をしたり、自動化したりして実行することができます. コードオーバーライドツール を使用
通常、あなたのテスト例がセグメントコードをチェックするときにどれだけ完備しているかを測定するのは難しいです.すべての実行パスを完全にテストできないと、システムの失敗を招く可能性のある深刻なアプリケーションバグを無視する可能性があります.オーバーライド率ツールは、AntまたはMavenコンパイルプロセスの一部になります.視覚的なオーバーライド率レポートを生成し、どの行がテストされたかを示します.100%のコードオーバーライド率を盲目的に追求してはいけません.100%のテストオーバーライド率でも完全なオーバーライドを保証することはできません.また,盲目的に高すぎるコードオーバーライド率を追求すると,投入/産出比が低下する.
ここにはいくつかのオープンソースツールがあります:Cobertura Emma EclEmma 適切なツールを使用してテストシーン を準備する.
JUnitは、Java環境でのユニットテストエンティティフレームワークを提供します.しかし、JUnitだけではコードのすべての機能を有効にテストすることは保証されません.適切なツールを見つけることが重要です.幸いなことに、コミュニティは多くのJUnitの拡張を開発しており、あなたが直面する可能性のあるさまざまな仮想シーンをテストすることができます.
異なるシーンをテストするときに、異なるテストツールを使用することができます.以下では、これらのツールについて説明します. 自動化テスト
junitとantを組み合わせて、一定の命名規則を通じて、ユニットテストコードを自動的に実行し、一連のレポートを生成します.mavenを使用するプロジェクトでは、maven-surefire-pluginプラグインを使用して自動化テストを行うことができ、便利です.
複数のメソッドは1つの動作を構成する可能性があり、1つのメソッドは複数の動作を含む可能性があり、1つのメソッドが複数の用途に使用できる場合、パラメータによって異なる表現がある可能性があります.各表現は1つの動作であり、複数のメソッドが1つの行を構成する場合があります.付随するメソッドは、メインメソッドでのみ使用され、メインメソッドのみをテストできます.
プライベートメソッドをテストする必要があるかどうか:
プライベートメソッドは一般的にテストが容易ではなく、複雑ではないプライベートメソッドに対しては、必然的に他の公有メソッドに呼び出されるため、一般的にテストを行わなくてもよい.プライベートメソッドが複雑であるか、開示されたメソッドで全面的にテストするのが難しい場合は、反射を使用してテストすることができます.
2.「Too Simple to Break」ルールの使用
テストセットで高いコードオーバーライド率を維持することは重要であるが、100%のオーバーライド率を獲得することは賢明ではない.収益の減少の観点を考慮しなければならない.良い経験は、1つの方法が分割できないほど簡単であれば、ユニットテストを書く必要はありません.「分割できないほど簡単」とは説明にもよるが、次の方法でユニットテストを書くのは役に立たない.
public String getName() {
return name;
}
簡単なアクセス方法のテストは望ましくない.
テスト作業は非常に時間のかかる作業であり、将来の時間を節約します.そのため、テストが有効であることを確認してください.良いテストは、モジュールごとにコア機能をテストするのではなく、細かくテストする必要があります.ソフトウェアシステムの動作に対してテストコードを記述する必要があります.あなたはすべてを必要としません.今考えているもののためにまずテストを作成し、それから他のことを考えてからもっとテストを増やします.
テスト用例を先頭などのコード資産を整理することが重要です.製品コードを書くのと同じデザインを使ってテスト例を書くべきです.これは、テスト例を再構築したり、汎用機能をベースクラスにアップグレードしたり、重複コードを削除したり、長い方法を分解したりする機会を探すことを意味します.これができないと変更の費用がかかり、時間が経つにつれてテストセットが無効になるという観点で説明する必要があることは、プロジェクトの実際の状況によって異なり、時間が短いプロジェクトでは、ユニットテストで大量のコピーが貼り付けられ、冗長コードが受け入れられる.
これは明らかに見えますが、次のようなテスト方法がよく見られます.
public void testGetUser1() {}public void testGetUser2() {}public void testGetUserWithInvalidUsername() {}public void testGetUserThrowsExpiredCredentialsException() {}代わりに、テストの目的を明確に記述できる方法名を使用する必要があります.このようにすると、あなたのテスト例がよりよく理解され、メンテナンスされやすくなります.例:
テストの成功または失敗は、開発者がコンソールを目視して結果を決定することに基づいてはならない.これはシステムを使うべきではないことを意味します.out.println()またはLogger.debug()文は、あなたのテストの成功状態を決定します.代わりに、JUnitの様々なassertXXX()メソッドに依存する必要があります.そのため、テストは無人の世話をしたり、自動化したりして実行することができます.
通常、あなたのテスト例がセグメントコードをチェックするときにどれだけ完備しているかを測定するのは難しいです.すべての実行パスを完全にテストできないと、システムの失敗を招く可能性のある深刻なアプリケーションバグを無視する可能性があります.オーバーライド率ツールは、AntまたはMavenコンパイルプロセスの一部になります.視覚的なオーバーライド率レポートを生成し、どの行がテストされたかを示します.100%のコードオーバーライド率を盲目的に追求してはいけません.100%のテストオーバーライド率でも完全なオーバーライドを保証することはできません.また,盲目的に高すぎるコードオーバーライド率を追求すると,投入/産出比が低下する.
ここにはいくつかのオープンソースツールがあります:Cobertura Emma EclEmma
JUnitは、Java環境でのユニットテストエンティティフレームワークを提供します.しかし、JUnitだけではコードのすべての機能を有効にテストすることは保証されません.適切なツールを見つけることが重要です.幸いなことに、コミュニティは多くのJUnitの拡張を開発しており、あなたが直面する可能性のあるさまざまな仮想シーンをテストすることができます.
異なるシーンをテストするときに、異なるテストツールを使用することができます.以下では、これらのツールについて説明します.
junitとantを組み合わせて、一定の命名規則を通じて、ユニットテストコードを自動的に実行し、一連のレポートを生成します.mavenを使用するプロジェクトでは、maven-surefire-pluginプラグインを使用して自動化テストを行うことができ、便利です.