ユニットテスト

ユニットテスト（コンポーネントテストまたはモジュールテストとも呼ばれる）は、分離されたソースコードをテストして期待される動作を検証するソフトウェアテストの一種です。 ^[1]

ユニット テストは、統合レベルまたはシステムレベルでのテストとは対照的に、ユニット レベルで実行されるテストを表します。

ユニットテストは、大規模なソフトウェアシステムの小さな部分を個別にテストする原理として、ソフトウェアエンジニアリングの初期の頃にまで遡ります。1956年6月、HDベニントンは、米国海軍のデジタルコンピュータの高度なプログラミング方法に関するシンポジウムで、SAGEプロジェクトとその仕様ベースのアプローチを発表しました。このアプローチでは、コーディング段階の後に「パラメータテスト」が行われ、コンポーネントサブプログラムが仕様に照らして検証され、その後、組み立てられたパーツに対して「アセンブリテスト」が行われます。^{[2] [3]}

1964年には、マーキュリー計画のソフトウェアについて同様のアプローチが説明されており、異なるプログラムで開発された個々のユニットは、統合される前に「ユニットテスト」を受けました。^[4] 1969年には、テスト方法論はより構造化され、個別に記述された個々の部分と、それらを段階的に組み立ててより大きなブロックにすることを確認するために、ユニットテスト、コンポーネントテスト、統合テストが導入されました。^[5] 60年代末に採用されたMIL-STD-483 ^[6]やMIL-STD-490などのいくつかの公的標準は、大規模プロジェクトでのユニットテストの幅広い受け入れにさらに貢献しました。

当時のユニットテストは、 コード化されたテストやキャプチャーアンドリプレイテストツールを使用したインタラクティブ^[3]または自動化された^{[7]ものでした。1989年、}ケント・ベックは「Simple Smalltalk Testing: With Patterns」でSmalltalkのテストフレームワーク（後にSUnitと呼ばれる）について説明しました。1997年、ケント・ベックとエリック・ガンマは、 Java開発者の間で人気となったユニットテストフレームワークであるJUnitを開発し、リリースしました。^[8] Googleは2005年から2006年頃に自動テストを採用しました。^[9]

ユニットは、テスト対象システム (SUT) が示す単一の動作として定義され、通常は要件に対応します。ユニットは関数またはモジュール (手続き型プログラミングの場合)、またはメソッドまたはクラス (オブジェクト指向プログラミングの場合) であることを意味する場合がありますが、関数/メソッド、モジュール、またはクラスが常にユニットに対応するわけではありません。システム要件の観点からは、システムの境界のみが関連しているため、外部から見えるシステム動作へのエントリポイントのみがユニットを定義します。^[10]

ユニット テストは、手動で実行することも、自動テスト実行によって実行することもできます。自動テストには、テストを頻繁に実行できること、人件費をかけずにテストを実行できること、一貫性があり繰り返し可能なテストを実行できることなどの利点があります。

テストは、多くの場合、テスト対象のコードを作成し、変更するプログラマーによって実行されます。ユニット テストは、コードの作成プロセスの一部と見なすことができます。

開発中、プログラマーはユニットの正確さを検証するために、基準または良好であることがわかっている結果をテストにコード化することがあります。

テスト実行中に、フレームワークはいずれかの基準に失敗したテストをログに記録し、概要で報告します。

この場合、最も一般的に使用されるアプローチは、テスト - 関数 - 期待値です。

パラメーター化されたテストは、複数の異なる入力値でテストを実行できるようにするために使用できる値のセットを受け入れるテストです。パラメーター化されたテストをサポートするテスト フレームワークは、パラメーター セットをエンコードし、各セットでテストを実行する方法をサポートします。

パラメーター化されたテストを使用すると、テスト コードの重複を減らすことができます。

パラメータ化されたテストは、TestNG、JUnit、^[13] XUnit、NUnit、およびさまざまなJavaScriptテストフレームワークでサポートされています。 ^{[引用が必要]}

ユニット テストのパラメータは手動でコーディングすることも、テスト フレームワークによって自動的に生成される場合もあります。近年では、理論の概念を活用したより強力な (ユニット) テストの作成のサポートが追加されました。これは、事前に定義された入力セットを使用して同じ実行手順を使用する通常のパラメータ化テストとは異なり、同じ手順を実行するテスト ケースですが、実行時に生成されたテスト データを使用します。^{[引用が必要]}

アジャイル ソフトウェア開発では、ユニット テストはユーザー ストーリーごとに実行され、要件収集と開発が完了した後のスプリントの後半に行われます。通常、開発者またはコンサルタントなどの開発チームの他のメンバーは、開発者がツールで実行するためのステップ バイ ステップの「テスト スクリプト」を作成します。テスト スクリプトは通常、エンド ユーザーがインターフェイスする本格的なビジネス プロセスではなく、ツールで開発された特定の機能の効果的かつ技術的な操作を証明するために作成されます。これは通常、ユーザー受け入れテスト中に行われます。テスト スクリプトが最初から最後まで問題なく完全に実行できる場合、ユニット テストは「合格」と見なされます。そうでない場合は、エラーが記録され、ユーザー ストーリーは「進行中」の状態で開発に戻されます。ユニット テストに合格したユーザー ストーリーは、スプリントの最終ステップであるコード レビュー、ピア レビュー、そして最後に、開発されたツールを利害関係者にデモンストレーションする「ショーバック」セッションに進みます。

テスト駆動開発 (TDD) では、実稼働コードの作成中にユニット テストが作成されます。開発者は、動作コードから始めて、必要な動作のテスト コードを追加し、次にテストに合格するのに十分なコードを追加し、意味のあるコード (テスト コードを含む) をリファクタリングし、別のテストを追加してこれを繰り返します。

ユニットテストは、ユニットが設計通りの動作をし、意図したとおりに動作することを確認することを目的としています。^[14]

最初にテスト可能な最小単位のテストを記述し、次にそれらの間の複合動作のテストを記述することで、複雑なアプリケーションに対する包括的なテストを構築することができます。^[14]

ユニットテストの目的の1つは、プログラムの各部分を分離し、個々の部分が正しいことを示すことです。^[1]ユニットテストは、コードが満たさなければならない 厳密な書面による契約を提供します。

ユニット テストは、開発サイクルの早い段階で問題を発見します。これには、プログラマーの実装のバグと、ユニットの仕様の欠陥または欠落部分の両方が含まれます。徹底した一連のテストを作成するプロセスにより、作成者は入力、出力、およびエラー条件について熟考する必要があり、ユニットの望ましい動作をより明確に定義できます。^{[引用が必要]}

コーディングを始める前、またはコードが最初に書かれたときにバグを見つけるコストは、後でバグを検出、識別、修正するコストよりもかなり低くなります。リリースされたコードにバグがあると、ソフトウェアのエンドユーザーにコストのかかる問題を引き起こす可能性もあります。^{[15] [16] [17]}コードの書き方が下手だと、単体テストが不可能または困難になる可能性があるため、単体テストによって開発者は関数とオブジェクトをより良い方法で構造化することができます。

ユニットテストはソフトウェア開発においてより頻繁なリリースを可能にします。個々のコンポーネントを個別にテストすることで、開発者は問題を迅速に特定して対処することができ、反復とリリースサイクルが速くなります。^[18]

ユニット テストを使用すると、プログラマーは後日コードをリファクタリングしたり、システム ライブラリをアップグレードしたりして、モジュールが引き続き正しく動作するかどうかを確認できます (例:回帰テスト)。手順としては、すべての関数とメソッドのテスト ケースを記述し、変更によって障害が発生した場合にすぐに特定できるようにします。

ユニット テストは、設計契約に違反する可能性のある変更を検出します。

ユニット テストはユニット自体の不確実性を軽減し、ボトムアップテスト スタイルのアプローチで使用できます。最初にプログラムの一部をテストし、次にその部分全体をテストすることで、統合テストがはるかに簡単になります。^{[引用が必要]}

プログラマーの中には、ユニット テストはコードのドキュメントの一種であると主張する人もいます。ユニットによって提供される機能とその使用方法を知りたい開発者は、ユニット テストを確認して理解を深めることができます。^{[引用が必要]}

テスト ケースには、ユニットの成功に不可欠な特性を組み込むことができます。これらの特性は、ユニットの適切/不適切な使用や、ユニットによってトラップされる否定的な動作を示すことができます。多くのソフトウェア開発環境では、開発中の製品を文書化するためにコードのみに依存しているわけではありませんが、テスト ケースはこれらの重要な特性を文書化します。^{[引用が必要]}

一部のプロセスでは、テストとテスト対象のコードの作成、および関連するリファクタリングが正式な設計に代わる場合があります。各ユニット テストは、クラス、メソッド、および観察可能な動作を指定する設計要素として考えることができます。^{[引用が必要]}

テストではプログラム内のすべてのエラーをキャッチできません。なぜなら、ごく単純なプログラム以外では、すべての実行パスを評価することはできないからです。この問題は、決定不可能な停止問題のスーパーセットです。同じことが単体テストにも当てはまります。さらに、単体テストは定義上、ユニット自体の機能性のみをテストします。したがって、統合エラーやより広範なシステムレベルのエラー (複数のユニットにまたがって実行される機能や、パフォーマンスなどの非機能テスト領域など) はキャッチされません。単体テストは、特定のエラーの有無を示すことしかできず、エラーがまったく存在しないことを証明することはできないため、他のソフトウェア テストアクティビティと組み合わせて行う必要があります。すべての実行パスとすべての可能な入力に対して正しい動作を保証し、エラーが存在しないことを確認するには、他の手法、つまり、ソフトウェア コンポーネントに予期しない動作がないことを証明するための形式手法の適用が必要です。 ^{[引用が必要]}

ユニット テストの複雑な階層構造は、統合テストと同じではありません。周辺ユニットとの統合は統合テストに含める必要がありますが、ユニット テストには含めないでください。^{[引用が必要]}統合テストは、通常、人間による手動テストに大きく依存しています。高レベルまたはグローバル スコープのテストは自動化が難しいため、手動テストの方が高速で安価であるように見えることがよくあります。^{[引用が必要]}

ソフトウェアテストは組み合わせの問題です。たとえば、すべてのブール判定ステートメントには、少なくとも 2 つのテストが必要です。1 つは結果が「真」で、もう 1 つは結果が「偽」です。その結果、記述されたコード 1 行ごとに、プログラマーは 3 ～ 5 行のテスト コードを必要とすることがよくあります。^[要出典]これには明らかに時間がかかり、その投資は労力に見合わない可能性があります。簡単にテストできない問題もあります。たとえば、非決定性の問題や複数のスレッドが関係する問題などです。さらに、単体テストのコードは、テスト対象のコードと同じくらいバグが多い可能性があります。フレッド ブルックスは「人月の神話」の中で、「海に行くときはクロノメーターを 2 つ持ってはいけない。1 つまたは 3 つ持って行こう」と述べています。^{[19]つまり、2 つの}クロノメーターが矛盾している場合、どちらが正しいのかをどうやって判断すればよいのでしょうか。

単体テストの作成に関連するもう 1 つの課題は、現実的で有用なテストを設定することの難しさです。テスト対象のアプリケーションの一部が完全なシステムの一部のように動作するように、適切な初期条件を作成する必要があります。これらの初期条件が正しく設定されていない場合、テストは現実的なコンテキストでコードを実行せず、単体テストの結果の価値と精度が低下します。^{[引用が必要]}

ユニット テストから意図したメリットを得るには、ソフトウェア開発プロセス全体にわたって厳格な規律が必要です。

実行されたテストだけでなく、このユニットまたはソフトウェア内の他のユニットのソース コードに加えられたすべての変更についても、注意深く記録しておくことが重要です。バージョン コントロールシステムの使用は不可欠です。ユニットの新しいバージョンが、以前に合格した特定のテストに合格しなかった場合、バージョン コントロール ソフトウェアは、その時点以降にユニットに適用されたソース コードの変更 (ある場合) のリストを提供できます。^{[引用が必要]}

また、テストケースの失敗が定期的にレビューされ、すぐに対処されることを保証する持続可能なプロセスを実装することも不可欠です。^[20]このようなプロセスが実装されておらず、チームのワークフローに根付いていないと、アプリケーションはユニットテストスイートと同期せずに進化し、誤検知が増加し、テストスイートの有効性が低下します。

組み込みシステムソフトウェアのユニットテストには、独特の課題があります。ソフトウェアは最終的に実行されるプラットフォームとは異なるプラットフォームで開発されているため、デスクトッププログラムのように実際の展開環境でテストプログラムを簡単に実行することはできません。^[21]

ユニットテストは、メソッドに入力パラメータと何らかの出力がある場合に最も簡単に作成できます。メソッドの主な機能がアプリケーションの外部とやり取りすることである場合、ユニットテストを作成するのはそれほど簡単ではありません。たとえば、データベースを操作するメソッドでは、データベースとのやり取りのモックアップを作成する必要がありますが、実際のデータベースとのやり取りほど包括的ではない可能性があります。^{[22] [より良いソースが必要]}

以下は JUnit テスト スイートの例です。Adderクラスに重点を置いています。

クラス Adder { public int add ( int a 、int b ) { return a + b ; } } 
          
           
    

テスト スイートは、assertステートメントを使用して、メソッドへのさまざまな入力値の予想される結果を検証しますsum。

static org.junit.Assert.assertEqualsをインポートします。org.junit.Testをインポートします。public class AdderUnitTest { @Test public void sumReturnsZeroForZeroInput () { Adder adder = new Adder (); assertEquals ( 0 , adder . add ( 0 , 0 )); } 
 
   
    
       
            
          
    

    @Test 
public void sumReturnsSumOfTwoPositiveNumbers () { Adder adder = new Adder ( ); assertEquals ( 3 , adder.add ( 1 , 2 )) ; }       
            
          
    

    @Test 
public void sumReturnsSumOfTwoNegativeNumbers () { Adder adder = new Adder (); assertEquals ( - 3 , adder . add ( - 1 , - 2 )); }       
            
          
    

    @Test 
public void sumReturnsSumOfLargeNumbers () { Adder adder = new Adder (); assertEquals ( 2222 , adder . add ( 1234 , 988 )); } }       
            
          
    

ユニット テストを設計仕様として使用すると、他の設計方法に比べて 1 つの大きな利点があります。設計ドキュメント (ユニット テスト自体) 自体を使用して実装を検証できるのです。開発者が設計に従ってソリューションを実装しない限り、テストは合格しません。

ユニット テストには、 UML図などの図式仕様のアクセシビリティが一部欠けていますが、自動化ツールを使用してユニット テストから生成できます。ほとんどの最新言語には無料のツールがあります (通常はIDEの拡張機能として利用できます) 。xUnitフレームワークに基づくものなどの無料ツールは、人間が使用できるビューのグラフィカル レンダリングを別のシステムにアウトソースします。

ユニット テストは、自動化されたユニット テスト フレームワークに依存するエクストリーム プログラミングの基礎です。この自動化されたユニット テスト フレームワークは、xUnitなどのサードパーティのものでも、開発グループ内で作成されたものでもかまいません。

エクストリーム プログラミングでは、テスト駆動開発に単体テストの作成を使用します。開発者は、ソフトウェア要件または欠陥のいずれかを明らかにする単体テストを作成します。このテストは、要件がまだ実装されていないか、既存のコードに意図的に欠陥があるために失敗します。次に、開発者は、テストとその他のテストをパスさせる最も単純なコードを作成します。

システム内のほとんどのコードは単体テストされていますが、必ずしもコードのすべてのパスがテストされているわけではありません。エクストリーム プログラミングでは、従来の「すべての実行パスをテストする」方法ではなく、「壊れる可能性のあるものはすべてテストする」戦略が求められます。これにより、開発者は従来の方法よりもテストを作成する回数が少なくなりますが、これは実際には問題ではなく、むしろ事実を言い換えたものです。従来の方法は、すべての実行パスを徹底的にテストするほど系統立てて実行されることはほとんどなかったからです。^[要出典]エクストリーム プログラミングは、テストが網羅的になることはめったにないこと (多くの場合、コストと時間がかかりすぎて経済的に実行できないため) を認識し、限られたリソースを効果的に集中させる方法についてのガイダンスを提供します。

重要なのは、テスト コードは実装コードと同じ品質で維持され、重複がすべて削除されるという点で、第一級のプロジェクト成果物と見なされることです。開発者は、テスト対象のコードと併せて、単体テスト コードをコード リポジトリにリリースします。エクストリーム プログラミングの徹底した単体テストにより、上記の利点、つまり、よりシンプルで信頼性の高いコード開発とリファクタリング、簡素化されたコード統合、正確なドキュメント、よりモジュール化された設計などが可能になります。これらの単体テストは、回帰テストの形式としても継続的に実行されます。

ユニットテストは、エマージェントデザインの概念にとっても重要です。エマージェントデザインはリファクタリングに大きく依存しているため、ユニットテストは不可欠な要素です。^{[引用が必要]}

自動テスト フレームワークは、テスト実行を自動化する機能を提供し、テストの作成と実行を高速化できます。さまざまなプログラミング言語向けにフレームワークが開発されています。

通常、フレームワークはサードパーティ製であり、コンパイラや統合開発環境(IDE) とともに配布されるものではありません。

フレームワークを使用せずにテストを記述し、アサーション、例外処理、その他の制御フローメカニズムを使用してテスト対象のコードを実行し、動作を検証して失敗を報告することもできます。フレームワークの導入には参入障壁があるため、フレームワークなしでのテストは価値があると指摘する人もいます。テストがまったくないよりはましですが、フレームワークが確立されれば、テストの追加はより簡単になります。^[23]

一部のフレームワークでは高度なテスト機能が欠落しており、手動でコーディングする必要があります。

一部のプログラミング言語は、ユニット テストを直接サポートしています。これらの言語の文法では、ライブラリ (サードパーティ製または標準) をインポートせずに、ユニット テストを直接宣言できます。さらに、ユニット テストのブール条件は、what is used forifおよびwhileステートメントなど、非ユニット テスト コードで使用されるブール式と同じ構文で表現できます。

ユニット テスト サポートが組み込まれている言語には次のものがあります。

標準のユニット テスト フレームワークをサポートする言語には次のものがあります。

一部の言語にはユニット テストのサポートが組み込まれていませんが、ユニット テスト ライブラリまたはフレームワークが確立されています。これらの言語には次のものが含まれます。

• Feathers, Michael C. (2005)。「レガシーコードでの効果的な作業」アッパーサドルリバー、ニュージャージー州： Prentice Hall Professional Technical Reference。ISBN 978-0131177055。
• Gulati, Shekhar; Sharma, Rahul (2017). JUnit 5 による Java ユニットテスト. Apress .

• テスト駆動開発 (Ward Cunningham の Wiki)