モジュールテストとは？定義、例

⚡ スマートサマリー

モジュールテストでは、組み立てられたプログラム全体ではなく、個々のサブプログラム、サブルーチン、クラス、プロシージャをチェックするため、欠陥は小さく理解しやすいコードブロック内で明らかになり、発見と修正が容易になります。

🎯 目的： 目的はモジュールのエラーを明らかにすることであり、モジュールが正しく動作することを証明することではない。
⚪ オリエンテーション： この手法は基本的にホワイトボックスであり、仕様書から抽出されたブラックボックスの事例によって補完されている。
⏩ 並列処理： 複数のモジュールを同時にテストできるため、全体のテスト期間を短縮できます。
🔗 2つの方法: モジュールは、段階的に、つまりステップごとに、または一度にまとめて、段階的ではなく非段階的に結合されます。
🧰 足場： ドライバはモジュールにテストデータを提供し、スタブはドライバが呼び出すモジュールの代わりとなる。
🆚 所有： テスターはコーディング後にモジュールテストを作成するのに対し、開発者はコーディング中にユニットテストを作成する。
⚠️ 課題： 非漸進的な作業、誤解されたテストダブル、頻繁なデバッグが、労力の大部分を消費する。

モジュールテストとは何ですか?

モジュールのテスト モジュールテストとは、プログラム内の個々のサブプログラム、サブルーチン、クラス、またはプロシージャを検証するソフトウェアテストの一種です。ソフトウェアプログラム全体を一度にテストするのではなく、モジュールテストではプログラムのより小さな構成要素をテストすることを推奨しています。

モジュールテストは、主にホワイトボックステストの手法に基づいています。モジュールテストの目的は、モジュールが正しく機能することを示すことではなく、モジュール内にエラーが存在することを示すことです。この逆転の発想が重要です。何も検出されなかったテストでは、ほとんど何も確認されていないのに対し、欠陥が明らかになったテストは、その役割を果たしたと言えるからです。

モジュールレベルのテストは、テストプロセスに並列処理を導入することを可能にします。なぜなら、完全なビルドを待つことなく、複数のモジュールを同時にテストできる機会が生まれるからです。

モジュールテストを行う理由

モジュールテストは、欠陥検出の経済性を変えるため推奨されます。

プログラムをより小さな単位で分割することで、エラーやバグを特定できる可能性が高まる。
複数のモジュールを同時にテストできるため、この手法は並列テストをサポートする。
各モジュールはそれぞれ独立して検証されるため、テストの複雑さを容易に管理できる。
モジュール内部で発見された欠陥は trac少量のコードで済むため、デバッグ時間が大幅に短縮されます。

モジュールテストを行うにはどうすればよいですか?

の設計テストケースはモジュールテストの重要な部分です。モジュールテストのテストケースを設計する際には、テスターは2つのことを考慮する必要があります。

モジュールの仕様
モジュールのソースコード

モジュールのロジックを分析するには、以下の1つ以上の方法を使用します。白い箱方法を適用し、これらのテストケースを補完するためにブラックボックスモジュール仕様へのメソッド。現実的な値は選択されたパスと同じくらい重要なので、準備してください。テストデータ事件の後ではなく、事件と並行して行う。

テストケースが設計されたら、次のステップはテスト用のモジュールを組み合わせることです。使用される方法は、 インクリメンタル または 非増分 方法。

非増分法 すべてのモジュールは個別にテストされます。まずすべてのモジュールを結合し、その後プログラム全体をテストします。
インクリメンタル方式 各モジュールはまずテストされ、その後、テスト済みコレクションに段階的に追加されます。段階的な再テストが実行されます。
段階的テストには 2 つのアプローチがあります。 トップダウン (NAIST) と ボトムアップ テスト。
選択したデータを用いてモジュールを実行するには、テストデータの供給、実行状況の監視、および結果の取得を行うためのドライバが必要です。

どちらの方法を選択するかは、準備の手間と診断の容易さのトレードオフによって決まる。

側面	インクリメンタル方式	非増分法
組み合わせ	一度に1つのモジュールをテスト済みのコレクションに追加します	すべてのモジュールを組み合わせ、その後一緒にテストしました。
足場が必要	さらに多くのドライバーとスタブが段階的に記述されています	実際のモジュールが存在するため、テストダブルの数が少なくなります。
誤った隔離	強力 - 障害は、追加されたばかりのモジュールを指し示します	弱点 ― 失敗はどこからでも発生する可能性がある
に最適	多数の相互作用するモジュールを備えた大規模な建造物	モジュール数が少なく、結合度が低い小規模プログラム

モジュールテストにおけるドライバとスタブ

前述のドライバは、一対のモジュールの片方です。テスト対象のモジュールが呼び出しチェーンの最上位または最下位に位置することは稀であるため、テスターは不足している部分をダミーコードで置き換えます。

ドライバ — テスト対象モジュールの上位にある呼び出し元モジュールを置き換えます。テストデータを提供し、モジュールを呼び出し、実行を監視し、結果をキャプチャします。下位モジュールは上位モジュールよりも先に準備が整うため、ボトムアップテストはドライバに依存します。
スタブ — テスト対象モジュールの下位にある呼び出し先モジュールを置き換えます。呼び出しを受け付け、固定された既知の応答を返すことで、テスト対象モジュールが処理を完了できるようにします。上位モジュールが先に準備完了となるため、トップダウンテストではスタブが不可欠です。

具体的なテストケースによって、ペアリングが明確になります。支払い計算モジュールが完成していても、それを呼び出すチェックアウト画面が未完成の場合、ドライバはモジュールに一連の注文合計金額を渡し、返された金額を記録します。モジュールが呼び出す税金検索サービスも未完成の場合、スタブは固定税率を返すため、計算は引き続き実行されます。これらの足場となるコードはどちらも出荷されません。実際のモジュールが到着すると両方とも破棄されるため、テストダブルの理解不足は、後ほど繰り返し発生する課題として挙げられます。

モジュールテストのヒントの例

モジュールテストを実施する前に考慮すべきいくつかのヒントを以下に示します。

Revテストケースを使用する前に、必ず確認してください。
相違点の原因について混乱が生じないようにする。
自動テストツールを使用する。
変更すべきでない変数を検証する。
自己テストを避けるため、テスター間でモジュールを交換してください。
テストケースを再利用してください。

5つ目のヒントは、その長さ以上に重要な意味を持ちます。開発者が書いたばかりのモジュールだけをテストすると、欠陥の原因となったのと同じ前提を繰り返してしまうため、モジュールを複数の担当者でローテーションさせることは、最も安価で品質向上につながる方法の一つです。

単体テストとモジュールテスト

多くのチームではこの2つの用語は interchangeably（互換的に）使用されているが、作成者と適用範囲は異なる。

モジュールのテスト	単体テスト
モジュールテストは、開発者がコードを作成した後にテスターが作成したテストの集合です。	単体テスト開発者がソフトウェア開発プロセス中に作成したテストの集合体です。
モジュールテストには、ユニットテストを組み合わせることが含まれる場合があります。	ユニットテストでは、ユニットを個別にテストすることができます。

モジュールテスト、コンポーネントテスト、統合テスト

モジュールテストは、混同しやすい2つの隣接するレベルと並んで位置づけられています。この表では、テスト対象と通常テストを実施する担当者によって、これらのレベルを区別しています。

側面	モジュールのテスト	コンポーネントテスト	統合テスト
試験中	1つのサブプログラム、クラス、またはプロシージャ	直接的な依存関係を持つ、自己完結型のコンポーネント	結合されたモジュール間のインターフェース
通常のオーナー	テスターは、コードが書かれた後に	テスター	統合テスター
足場	ドライバーとスタブ	外部依存関係のスタブ	テストダブルの数が徐々に減少
欠陥が露呈	モジュール内部の論理エラー	コンポーネントの動作エラー	インターフェースおよびデータ転送エラー

日常使用においてコンポーネントのテストモジュールテストはしばしば同じ活動として扱われますが、統合テスト個々のモジュールがそれぞれ単独で合格した場合にのみ開始されます。

モジュールテストの課題

これらは、モジュールテストを導入する際にチームが最も頻繁に直面する課題です。

非増分テストにはより多くの作業が必要です すべてを最初に組み合わせるということは、たった一つの不具合でも、テスターがプログラム全体をやり直さなければならない可能性があるということだ。
テストダブルの誤解 非現実的な値を返すスタブは、何も証明しないグリーン実行結果を生み出す。
テストのデバッグは頻繁に行われます ― スキャフォールディングコード自体にも欠陥があり、ドライバの修正に費やす時間は、モジュールのテストに費やす時間を失うことになる。
コードを理解する必要がある — ホワイトボックスの向きは、モジュールを読めないテスターが、そのモジュールに対して意味のあるテストケースを設計できないことを意味する。

よくあるご質問

xUnitファミリーはほとんどの言語に対応しており、モックライブラリがスタブを提供し、カバレッジツールがどのパスに到達したかを示します。選択はテストレベルではなく、モジュールの言語に基づいて行われます。

モデルはモジュールのソースコードを読み込み、分岐を列挙し、手動によるチェックでは見落とされがちな境界値を含め、それぞれの分岐に対するケースを提案します。 Rev生成されたケースは仕様が要求することではなく、コードが何をするかを表明するため、iew は依然として必要です。

はい、そして、このようなアシスタントが最も効果を発揮するのは、スキャフォールディングの段階です。なぜなら、ドライバやスタブは、構造が既知の反復コードだからです。ただし、返される値については、人間の判断が必要です。もっともらしく見えるスタブが、まさに探している欠陥を隠してしまう可能性があるからです。

モジュール内のすべての分岐と境界が少なくとも一度は実行されるようにすれば十分です。パーセンテージ目標だけでは誤解を招く可能性があります。なぜなら、ステートメントの網羅率が高くても、決定結果全体が試されない場合があるからです。

モジュールのコンパイル後、かつそのインターフェースがまとめて実行される前に実施されます。これは納品されたコードに対して最初に適用されるテスト段階であり、ここで発見された欠陥は統合テストやシステムテストの段階に到達することはありません。

既存のコードに従ってください。トップダウン方式は、制御ロジックを最初に記述し、下位モジュールをスタブ化するプロジェクトに適しています。ボトムアップ方式は、ユーティリティモジュールを最初に実装し、ドライバがそれらを呼び出すプロジェクトに適しています。

このモジュールは正常にコンパイルされ、仕様書も利用可能で、依存関係も存在するか、あるいはスタブ化されており、テストデータも準備済みです。仕様書なしで始めると、この作業は単なるコードの説明になってしまいます。

テストでは、モジュールに欠陥がないことを証明することはできず、テストされたケースに耐えられたことしか証明できません。したがって、モジュールを壊そうとする実行を設計することで、合格が期待される実行を設計するよりも多くの情報が得られます。