JP2006268858A - アプリケーションホスト環境においてユニットテストを実行する方法および装置 - Google Patents

Abstract

【課題】ユニットテストが準備される開発環境を提供する。
【解決手段】ユニットテストは、プログラムユニットのより完全で正確なテストのためにホスト環境３２０において実行する。開発環境３１０では、ホスト環境３２０で作動しているアダプタ３２２にアクセスするためにテスト実行シム３１４を使用する。ホストアダプタ３２２は、特定のテストを実行する他のプログラムオブジェクトを呼び出すことができる。そのようなオブジェクトは、テスト対象ユニットに実行時バインドすることができる。アクセサクラスは特定のテスト対象ユニットへの実行時バインディングを容易にすることができ、開発環境３１０において制作されたテストがテスト対象ユニットにアクセスするために必要なコンテキストに応じた情報を使用できるようにすることも容易にする。
【選択図】図３

Description

本発明は一般に、ソフトウェア開発に関し、具体的にはソフトウェアコンポーネントのテストに関する。

多くの場合、ソフトウェアが開発、変更、または最適化される際、ソフトウェアをテストすることが望ましい。ソフトウェアは「ブラックボックス」としてテストされる場合があるが、これはつまり、ソフトウェアを活性化するために入力が適用され、これに応じて生成される出力が観察され、適正に機能するソフトウェアに予想される応答と比較されることを意味している。このように行うテストは通常、既存の外部インターフェース、すなわち動作中にソフトウェアとデータを交換するために使用されるインターフェースを使用してソフトウェアに適用される入力および出力に依存している。

図１Ａは、そのようなテスト手法を示している。開発環境１１０およびホスト環境１２０が使用される。テストは、開発環境１１０において準備される。テスト対象のプログラムは、ホスト環境１２０において動作する。ホスト環境１２０は、インターフェース１２２および１２４を含んでいる。

開発環境は多くの場合、プログラムを作成またはテストする開発者のコンピュータ上で確立されたプロセスである。開発環境は、開発者のプログラムの作成またはテストの作成を支援するツールを提供するコンポーネント、テストを実行するためのテスト環境を提供するコンポーネントなど、複数のコンポーネントを備えることができる。ホスト環境は多くの場合、同一のコンピュータまたは別個のコンピュータ上のプロセスである。ホスト環境は、人間のユーザーまたは開発環境のいずれかによってホストアプリケーションにテストが開始されるときに、オペレーティングシステムによって作成される。

開発環境１１０は、エージェント１１２を含んでいる。エージェント１１２は、個々のテストのタイミングおよび順序付けを制御するソフトウェアプログラムである。エージェント１１２はまた、これらのテストの結果を予想される結果と比較することができ、テストの結果を処理するかまたは人間の開発者あるいはシステムの他の部分に報告することができる。エージェント１１２は、１１４Ａ、１１４Ｂ、および１１４Ｃなどのテストを呼び出す。図示されている実施形態において、エージェント１１２は、テストアダプタ１１３を通じてテストを呼び出す。実行される各テストは、すべてのテストへの標準インターフェースをエージェント１１２に提供する各自のテストアダプタを有することができる。各々のテストは入力を適用し、ホスト環境１２０内で実行しているテスト対象プログラムからの出力を観察する。

ホスト環境１２０は、拡張可能インターフェースを通じてアドインプログラムを受け入れられるアプリケーションによって作成することができる。たとえば、Ｗｏｒｄ（商標）文書処理アプリケーションまたはＥｘｃｅｌ（商標）スプレッドシートアプリケーションのようなマイクロソフト（登録商標）Ｏｆｆｉｃｅ（商標）アプリケーションスイートのアプリケーションは、アドインプログラムを受け入れる。アドインプログラムは、ユーザー作成のものであっても、他のソースからのものであってもよい。アドインプログラムは、１つまたは複数のユニットから形成することができる。さらに、ホスト環境は、テストされることもある１つまたは複数のユニットを含むことができる。図１Ａにおいて、テストされるホスト環境１２０内のユニットは、総称的に、１２６Ａ、１２６Ｂ、および１２６Ｃなどのユニットによって示される。

ユニットは、ブラックボックステストを使用してテストされる。ブラックボックステストの場合、テスト対象のプログラムは、インターフェース１２２または１２４などの外部インターフェースを通じてアクセスされる。たとえば、図１Ａは、インターフェース１２２を通じて入力を適用し、インターフェース１２４を通じて結果を取得するテスト１１４Ａ．．．１１４Ｃを示している。実際の結果と予想される結果を比較することにより、テスト対象のプログラムのパフォーマンスを検証することができる。

ブラックボックスとしてソフトウェアをテストすることの欠点は、ユニットのすべてに完全に実行するために多くの入力または入力の組み合わせが必要になることである。さらに、特定の入力のセットに応じて予想された出力が観察されないために障害が検出される場合は、障害を修正するために変更する必要のある特定のコードのユニットを識別することが困難になる。

アプリケーションプログラムをテストする代替の手法は、図１Ｂに示されている。図１Ｂでは、ユニット１２６Ａなどのテスト対象のユニットは、テスト環境１３０にロードされる。「テストハーネス（ｔｅｓｔ ｈａｒｎｅｓｓ）」と呼ばれることもあるエージェント１１２は、テスト１５４の呼び出しなどによって、実行されるテストの選択および順序付けを同様に制御する。しかし、図１Ｂの例では、テストはテスト対象の単一ユニットで行われ、開発環境またはテスト環境において実行される。

開発環境１３０は、書き込みテストにおいて開発者を支援するツールを含んでいる。たとえば、マイクロソフトＶｉｓｕａｌ Ｓｔｕｄｉｏ（商標）開発環境は、開発者がテストを制作し、これらのテストの実行を制御し、結果を分析できるようにするツールを含んでいる。マイクロソフトＶｉｓｕａｌ Ｓｔｕｄｉｏ開発環境に含まれているツールの１つの機能は、インテリセンス（ＩｎｔｅｌｌｉＳｅｎｓｅ）として知られている。インテリセンス機能は、コードエディタのユーザーにコンテキストに応じたヘルプを提供する。たとえば、ユーザーがプログラム内の変数にアクセスするコードを制作している場合、インテリセンス機能は、そのプログラム内の変数のリストをユーザーに提供し、使用すべき正しい変数をユーザーがすばやく選択できるようにするか、またはユーザーが命令の入力を始めるとコードエディタが正しく命令を完了するようにできる。

Ｖｉｓｕａｌ Ｓｔｕｄｉｏ開発環境を使用して図１Ａに示されるテスト構成のためのテストを作成するテスト開発者は、テスト対象のコードを含むホスト環境のプロジェクトが、テストプログラムを含む開発環境のプロジェクトにおいて参照される場合、インテリセンス機能を使用することができる。ただし、あるプロジェクトを参照する別のプロジェクトにおいて使用できるのは、そのプロジェクトからのパブリックインターフェースだけである。したがって、インテリセンス機能は、テスト対象のユニットの非パブリック部分にアクセスするのには使用することができない。

ソフトウェアのユニットをテストする改良された方法を備えることが望ましいと考えられる。

本発明は、テストをホスト環境で実行できるようにする、ソフトウェアユニットのテストを実行する方法に関する。ホスト環境内のテストは、ホストがテスト対象ユニットを適切に初期化して、ホストアプリケーションによって提供されるコンテキスト情報がテスト中に使用できるようにすることを保証する。したがって、より完全で正確なテストが可能である。もう１つの態様において、開発環境とホスト環境との間のインターフェースは、テスト対象ソフトウェアのメソッド、プロパティおよびその他のパラメータが、たとえ非パブリックであっても、開発環境で使用可能にするような方法で提供することができる。この機能により、動的にインスタンス化されるプログラムのテストの生成が可能になる。さらに、特定のユニットのテストプログラムを準備する開発者にコンテキストに応じた情報を提供することを可能にする。

１つの態様において、本発明は、第１の環境において動作するプログラムをテストする方法に関する。そのような方法は、少なくとも１つのユニットがテストされる複数のユニットを有するプログラムをテストする場合に有用である。この方法は、第２の環境においてテストエージェントを実行するステップを備える。テストエージェントは、テスト対象ユニットをテストするために実行されるテストを指定する。テストエージェントの実行に応じて、指定されたテストが第１の環境において実行される。このテストは、テスト対象ユニットのパフォーマンスを示すテスト結果を生成する。第１の環境において動作する指定されたテストからのテスト結果は、第２の環境において動作するテストエージェントに伝達される。

もう１つの態様において、本発明は、第１の環境において動作するプログラムをテストする方法に関する。この方法は、少なくとも１つのユニットがテスト対象である複数のユニットを有するプログラムをテストする場合に有用である。この方法は、第１の環境においてプログラムをロードするステップ、および第１の環境においてオブジェクトのインターフェースを公開するステップを備えている。オブジェクトは、インターフェースを通じて提供される情報に応じてテストアダプタをロードするために使用される。テストアダプタは、テスト対象ユニットのテストを実行する。

さらにもう１つの態様において、本発明は、複数のホスト環境の１つにおいて動作するプログラムのユニットをテストするためにテストプログラムが開発される開発環境を提供するソフトウェアシステムを実装するステップを実行するためのコンピュータ実行可能命令を有するコンピュータ可読媒体であって、このコンピュータ実行可能命令は、テストエージェントを作成するステップと、複数のホストアダプタの１つを作成するステップで、各ホストアダプタは複数のホスト環境の１つにおいてテストプログラムの実行を呼び出すためにテストエージェントによって使用されるように構成されるステップとを実行するコンピュータ可読媒体に関する。

添付の図面は、請求の範囲を縮小することを意図して描かれたのではない。図面において、さまざまな図に示されている各々の同一またはほぼ同一のコンポーネントは、類似した番号で表されている。明瞭さを期すため、すべての図面においてすべてのコンポーネントにラベル付けされているわけではない。

図１Ｂによって示されているテスト方法の欠点は、テスト対象ユニット１２６Ａが開発環境１３０において実行されることである。テスト対象ユニット１２６Ａがホスト環境１２０からのコンテキスト情報を必要とする場合、その情報はテスト中に使用することができない。ホスト環境１２０からコンテキスト情報にアクセスするかまたはこれに依存するテスト対象ユニット１２６Ａの一部を実行するテスト対象のユニット１２６Ａの任意のテストは、失敗する可能性が高い。テストは、テスト対象ユニットが正しくない結果を返したため、またはテスト対象ユニットがコンテキスト情報なしで動作できなかったために失敗することがある。

さらに、図１Ｂの方法は、テスト対象のコードが実行時に構築される場合には使用することができない。たとえば、ＡＳＰ．ＮＥＴは、実行時の条件が、作成されるコードを定義できるようにするプログラミング環境である。そのようなコードに対して、テストハーネスは、コードが定義されるまで構築することができない。

図２Ａは、テスト実行のための望ましいアーキテクチャを示している。開発環境１１０において実行されるエージェント１１２は、テスト２１４を呼び出す。テスト２１４は、ホスト環境１２０で実行するテスト対象のユニット２２６にアクセスする。それがプログラムされる特定のアプリケーションおよび言語に応じて、テスト対象ユニット２２６は、ホスト環境１２０におけるアドインプログラムまたはアプリケーションプログラムの関数、プロシージャ、メソッド、オブジェクト、またはその他の構成体（ｃｏｎｓｔｒｕｃｔ）の１つまたは組み合わせであってもよい。

図２Ｂは、代替の実施形態を示している。図２Ｂの実施形態において、テスト２１４は、ホスト環境１２０内で実行され、開発環境１１０のエージェント１１２と通信する。この実施形態において、テスト２１４はさらに、ホスト環境１２０からコンテキスト情報に直接アクセスすることができる。

図２Ａおよび図２Ｂに示される構成により、テスト対象のユニット２２６がそのホスト環境においてテストされるようにできる。テスト対象ユニット２２６がホスト環境１２０の属性、変数、またはその他のパラメータに依存する場合、テストされるときにそれらの属性、変数、またはその他のパラメータにアクセスすることができる。同様に、テスト対象ユニット２２６の動作がホスト環境１２０で行われる初期化に依存する場合、テスト対象ユニット２２６はテストに先立ってホスト環境において初期化される。従来技術のテスト構成と比較すると、図２Ａまたは図２Ｂのアーキテクチャで実施されるテストは、実際の動作条件をより正確に表現し、ホスト環境１２０の一部のパラメータに依存するテスト対象ユニット２２６のコードの一部を実行しようとする場合に失敗するかまたは例外条件を作成する可能性は低い。

図２Ａまたは図２Ｂに示されているアーキテクチャは、テスト対象ユニット２２６が非パブリックインターフェースを含む場合など、一部の状況において増強することができる。本明細書で使用されているように、「非パブリック」インターフェースという用語は、インターフェースがプログラミング言語の標準機能を使用して定義されるプログラム領域の外部のコードからプログラミング言語の標準機能を使用してアクセスできないインターフェースを意味している。「非パブリック」インターフェースの例には、「インターナル（ｉｎｔｅｒｎａｌ）」、「プロテクテッド（ｐｒｏｔｅｃｔｅｄ）」、または「プライベート（ｐｒｉｖａｔｅ）」と呼ばれるものがある。たとえば、一部のプログラミング言語においてプログラムは「プロジェクト」で作成される。別のあるプロジェクトを参照することにより、あるプロジェクト内のパブリックインターフェースはもう一方のプロジェクト内で使用できるようになるが、非パブリックインターフェースはそれが定義されているプロジェクト内でしか使用することができない。

テスト対象ユニット２２６が動的にインスタンス化されるか、コンパイルされるか、あるいはテスト２１４がコンパイルされるかまたは別の方法で生成される時点で使用できない場合は、追加のコンポーネントが望ましい。これらのシナリオにおいて、増強は、開発環境１１０における、インテリセンス機能を含むようなツールが、たとえテスト対象ユニット２２６の変数、メソッドまたはその他のパラメータに関する情報に直接アクセスできなくても、テスト対象ユニット２２６を実行するテストを制作するために必要なコンテキストに応じた情報を適切に表示できるようにすることができる。

図３は、たとえテスト対象ユニット２２６が直接アクセス可能ではない場合でも、テスト対象ユニット２２６をそのホスト環境１２０においてテストされるようにできるテストアーキテクチャの代替実施形態を示している。図３の実施形態はまた、商用開発環境において望ましいと考えられるカプセル化を示している。たとえばカプセル化により、開発環境は、比較的少数の追加ソフトウェアコンポーネントだけが新しい各ホスト環境または新しい各テストとインターフェースをとる複数のホスト環境および複数のテストと接続して使用できるようになる。

図３の実施形態において、エージェント３１２は開発環境３１０で実行される。従来技術におけるように、エージェント３１２は、テストの実行を調整し、テストの結果を受け取り、ユーザーとのインターフェースをとるか、あるいはテストの結果を報告または使用するプログラムである。この例において、エージェント３１２は、Ｃ＃プログラミング言語で書かれた関数であるが、任意の適切なプログラミング構成体を使用してエージェントを実装することができる。

示されている実施形態において、エージェント３１２は、テスト実行シム（ｔｅｓｔ ｅｘｅｃｕｔｉｏｎ ｓｈｉｍ）３１４と対話する。テスト実行シム３１４は、従来技術においてエージェントによって呼び出されるテストアダプタ１１３などのテストアダプタに取って代わる。テスト実行シム３１４のインターフェースがテストアダプタ１１３へのインターフェースと同じ場合、テストエージェント３１２は従来技術におけるように、あるいは任意の他の適切な方法で構築することができる。

テスト実行シム３１４は、ホスト環境３２０に特有の任意のインターフェースをカプセル化する。商用開発環境において、開発システムは、ホスト環境３２０のタイプをリフレクションするように設定できるホストタイプ属性を認識することができる。複数のホストアダプタが使用可能であり、同じ開発環境が複数のホスト環境にテストを準備するために使用できるようにする。たとえば、同じ開発環境を使用して、マイクロソフトＷｏｒｄ文書処理アプリケーションまたはマイクロソフトＥｘｃｅｌスプレッドシートアプリケーション用に作成されたアドインプログラムのテストを開発することができる。本明細書に説明されている実施形態において、ホストタイプごとに１つのテスト実行シムがあってもよい。この例において、各テスト実行シムはＶｉｓｕａｌ Ｂａｓｉｃの関数のセットであるが、任意の適切なプログラミング構成体を使用してテスト実行シムを実装することができる。

テスト実行シム３１４は、インターフェースの片側にホスト環境で動作するプログラムを提供する。ここで、そのインターフェースの反対側は、ホスト環境３２０のホストアダプタ３２２によって提供される。図３において、通信はインターフェース１２２を通じて行われることが示されている。さらに一般的には、テスト実行シム３１４とホストアダプタ３２２との間の通信は、任意の適切な通信チャネルを通じて行うことができる。開発環境３１０およびホスト環境３２０の特定の実装に応じて、適切な通信チャネルの例には、共用メモリスペース、名前付きパイプ、ＲＰＣインターフェース、またはＣＯＭインターフェースが含まれる。もう１つの例として、通信チャネルは、市販されている．ＮＥＴホスト環境で「リモーティング（ｒｅｍｏｔｉｎｇ）」構成体を使用して作成することができる。

動作中、ホスト環境３２０（または一部のアドインプログラム）は、ホスト環境がテストモードで操作されていることを認識して、ホストアダプタ３２２を初期化する。ホストアダプタ３２２の初期化の一部として、ホストアダプタ３２２へのインターフェースは、開発環境において実行するプログラムに使用可能になる。テストモードで動作中であっても、ホスト環境３２０はテスト対象ユニット２２６をロードして初期化し、テスト対象のユニット２２６がホスト環境に存在するようにする。特定のホスト環境および特定のテスト対象ユニットに応じて、ホスト環境３２０はテストモードでテスト対象ユニット２２６の実行を初期化する場合もしない場合もある。さらに、特定の実装に応じて、テスト対象ユニットの実行は行われるテストによって、または他の適切な方法で呼び出すことができる。

ホスト環境と開発環境との間の通信チャネルにより、開発環境のエージェント３１２はホスト環境のテスト３３０の実行を初期化して制御し、テスト３３０の実行の結果を受け取ることができる。

ホストアダプタ３２２の特定の実装は、ホスト環境３２０によって決まる。一例として、ホスト環境３２０がマイクロソフトＯｆｆｉｃｅアプリケーションである場合、ホストアダプタ３２２はＶｉｓｕａｌ Ｂａｓｉｃの関数のセットとすることができる。ホストアダプタの一例を与える擬似コードは、本明細書の後段のコンピュータプログラムリストに含まれている。

ホスト環境がテストモードに置かれるメカニズムはまた、開発環境の実装によって決まる。ＡＳＰ．ＮＥＴホスト環境の例では、テストの実行はＨＴＴＰモジュールの使用を伴う。テスト実行シム３１４は、テストモードが入力されることを指定するヘッダを含むＨＴＴＰ要求の送信をトリガすることができる。要求はさらに、テストされるユニットも示すことができる。テストモードを初期化するために使用される特定のメカニズムにはかかわりなく、テスト対象ユニット２２６はホスト環境３２０において初期化される。

ホストアダプタ３２２は、特定のテスト３３０を呼び出す。さらなる抽象化のために、ホストアダプタ３２２はテストアダプタ（図３には図示せず）を通じて特定のテストメソッドにアクセスすることができる。各テストは、すべてのテストアダプタがホストアダプタ３２２への共通インターフェースを提示して、各自のテストアダプタを有することができる。このようにして、ホスト環境には１つのホストアダプタ３２２が必要になるが、このホスト環境において任意の数のテストを呼び出すことができる。テストを実行する場合にテストに提供されるパラメータの数およびタイプなど、各テストの特定の要件はテストアダプタにカプセル化することができる。

いったん呼び出されると、テスト３３０はテスト対象ユニット２２６と対話してテスト対象ユニットを活性化させ、活性化に対するその応答を観察する。特定のテスト対象ユニットの構造および機能と行われるテストの特性に応じて、テスト対象ユニット２２６に活性化を提供するさまざまな形態が可能である。たとえば、テストは、そのユニットのメソッドを呼び出し、メソッド呼び出しの引数としてあらかじめ決められた値を与えることにより、テスト対象ユニットに活性化を提供することができる。

図３の実施形態では、テスト３３０はアクセサ（ａｃｃｅｓｓｏｒ）を通じてテスト対象ユニット２２６にアクセスする。アクセサは、ユニットのメソッド、プロパティ、クラスまたはその他のパラメータを判別するためにリフレクションを使用するプログラムである。アクセサは、テスト対象ユニット２２６へのアクセサクラスの実行時バインディングによって作成することができる。アクセサクラスが使用される場合、テスト開発者は、テスト対象ユニットの詳細を知ることなくアクセサクラスを参照するテスト３３０のようなテストプログラムを作成することができる。

アクセサクラスの実行時バインディングによってアクセサを作成する１つの方法は、「リフレクション」を使用することである。「リフレクション」は、ユニットが、メソッド、プロパティ、クラスまたはその他のパラメータに関する情報を保持するデータ構造体を読み取れるようにする多くのプログラミング言語の特性である。リフレクションされた情報は、アクセサ３３２をインスタンス化するために使用して、テストのターゲットである特定のテスト対象ユニット２２６にアクセスできるようになっている。

アクセサ３３２の実行時バインディングは、テスト対象ユニット２２６が動的にインスタンス化される場合に特に有利である。アクセサ３３２は、テスト対象ユニット２２６がインスタンス化される前であっても使用可能であるため、テスト対象ユニット２２６にアクセスするために必要な情報は開発環境３１０において使用可能であり、インテリセンスのような機能が、開発中のテストまたはテスト対象ユニット２２６を有するプログラムのコンテキストに応じた情報を表示するために必要な情報を備えることができるようになる。このようにして、テスト３３０は、コードを認可するために一般に使用可能なあらゆる種類のツールを使用して作成することができる。

別個のアクセサを使用してテスト対象ユニット２２６によってリフレクションされた情報を受信する必要はない。１つの代替実施形態の例として、同じ機能をテスト３３０に組み込むこともできる。

テスト３３０が結果を生成すると、それらの結果はエージェント３１２に渡して戻すことができる。結果は、ホストアダプタ３２２を通じて渡すことができる。代替として、結果は、開発環境に直接渡すことができる。たとえば、エージェント３１２またはテスト実行シム３１４は、パブリックインターフェースを含むことができる。テスト３３０は、エージェント３１２またはテスト実行シム３１４の後に開発環境において作成することができるので、エージェント３１２またはテスト実行シム３１４のインターフェースはテスト３３０がアクセスできるようにすることができる。

図３は、開発環境３１０においてエージェントによって実行されるコマンドに応じてホスト環境３２０で初期化され実行されるテスト対象ユニット２２６の一般化された表現である。一般化された表現は、特定のテスト対象コードがテストのコンパイル時に不明であるかまたは使用可能でなくても、テストを開発環境において開発できるようにする機能を含んでいる。そのようなテストアーキテクチャは、開発環境およびホスト環境と互換性のある任意の適切な手法で実装することができる。

図４は、開発環境で作成されたテストがＡＳＰ．ＮＥＴ環境を代表するホスト環境において実行されるプロセスの図である。この例のテストは、Ｗｅｂサイトを実装するアプリケーションプログラムの動作を検証することができる。説明される実施形態において、開発環境は、説明されるようにインターフェースを容易にするためにテスト対象のＷｅｂサイトのｗｅｂ．ｃｏｎｆｉｇファイルにアクセスすることができる。

１つまたは複数のテストを制作したのち、人間のユーザーは、開発環境３１０のコマンドラインインターフェースを通じてテストを呼び出すことができる。図４の例において、テストを実行することにより、エージェント４１０は開発環境３１０で稼働し、テストの実行を制御する。この実施形態において、エージェント４１０は、Ｃ＃言語で作成されたプログラムとすることができる。これは、実行されるテストを作成するために使用した同じ開発環境で稼働することも、あるいは、全く別個の開発環境または異なるコンピュータ上でも稼働することができる。

特定のホスト環境においてユニットをテストするため、エージェント４１０はそのホスト環境にインターフェースをとるように適合されるテスト実行シム４１２をインスタンス化する。この例において、テスト実行シム４１２は、ＡＳＰ．ＮＥＴホスト環境へのインターフェースを含んでいる。開発環境は、実行されるテストごとに複数のテスト実行シムを含むことができる。各テスト実行シムは、異なるホスト環境に対してホストアダプタとしての役割を果たすことができる。

説明される実施形態において、テスト実行シムは、それが対話を行う特定のホスト環境にはかかわりなく、定義済みフォーマットのインターフェース４３２を備えている。このようにして、エージェント４１０は、任意のテスト実行シムとやりとりすることができる。各テストは、エージェント４１０が任意の望ましいテストにアクセスできるインターフェースを提供されるように、別個のテスト実行シム４１２を有することができる。テスト実行シム４１２は、テスト対象ユニットを含むホスト環境３２０のアプリケーションにアクセスするコマンドを送信する。ホスト環境がＡＳＰ．ＮＥＴ環境であると説明されている実施形態において、アクセスはＨＴＴＰ要求を発行することにより行われる。ＨＴＴＰ要求は、テストされるプログラムまたはプログラムオブジェクトを指定する。この例において、プログラムオブジェクトはＵＲＬによって識別されるページである。ＨＴＴＰ要求は、ホスト環境がテストモードで呼び出される必要があることと、さらにテストのターゲットである特定のＵＲＬとを示す。

ホスト環境３２０は、テスト実行シム４１２によって送信された要求に応答する。要求に応じて、ＨＴＴＰモジュール４５０が呼び出される。モジュール４５０によって代表される特定のＨＴＴＰモジュールは、テスト実行シム４１２からの要求に応じて具体的に作成することができる。要求に応じて以前呼び出されたモジュールが破棄されている場合は、新しいモジュールが使用される。しかし、未使用のモジュールが破棄されていない場合は、要求の処理に使用することができる。ＡＳＰ．ＮＥＴのステートレス（ｓｔａｔｅｌｅｓｓ）の特性により、ＨＴＴＰモジュールの再使用はＡＳＰ．ＮＥＴホスト環境において可能である。他のホスト環境は、異なる動作を行うことができる。ＨＴＴＰモジュール４５０の特定のフォーマットおよび作成の方法は、ホスト環境３２０の実装によって決まり、テスト要求に応答する任意の適切な方法を使用することができる。

テスト実行シム４１２からの要求に応じて、ＨＴＴＰモジュール４５０はホスト環境における通常の処理に従ってターゲットページを初期化する。このようにして、テスト対象ユニットはホスト環境によって適切に初期化され、テストの準備が整う。この例では、ターゲットページはテスト対象ユニット４６０として示されている。さらに、ＨＴＴＰモジュール４５０はホストアダプタ４５４をロードし、これをテスト実行シム４１２に登録し、これによりホストアダプタ４５４へのインターフェースをテスト実行シム４１２に公開する。

ホストアダプタ４５４は、開発環境３１０へのインターフェースを提供する。図４の例では、ホストアダプタ４５４はＣ＃関数として実装される。

ホストアダプタ４５４は、開発環境で実行しているプログラムによってアクセスできるインターフェース４８０を備えている。ホスト環境３２０がＡＳＰ．ＮＥＴによって提供される、説明される実施形態において、他の環境のプログラムによるアクセスを対象としたあるソフトウェアプログラムへのインターフェースは、あるプログラムが別のプログラムに登録できるようにする．ＮＥＴリモーティング構成体を通じて公開することができる。ここで、ホストアダプタ４５４とインターフェースをとるために必要な情報は、．ＮＥＴレジスタコマンドを使用してインターフェース４３６を通じてテスト実行シム４１２が使用できるようになる。

インターフェース４８０がテスト実行シム４１２に登録されると、テスト実行シム４１２はインターフェース４８０を通じてホストアダプタ４５４と通信することができる。インターフェース４８０を通じて、テスト実行シム４１２は、特定のテストを実行するために使用されるテストアダプタ４５６上の情報を要求することができる。任意の適切なコマンドを使用して情報を取得することができるが、この例ではインターフェース４８０のメソッドが使用される。このように、テスト実行シム４１２はこの場合も、テストアダプタ４５６のインターフェース４８２にアクセスすることができる。この実施形態において、テストアダプタ４５６は、ホスト環境において実行されるすべてのテストの一貫したインターフェースを提供するラッパー（ｗｒａｐｐｅｒ）である。テストアダプタ４５６は、Ｃ＃関数として、または他の適切な方法で実装することができる。

テストアダプタ４５６は、テスト対象ユニット４６０で実行される特定のテスト４１６に特有のユニットテストアダプタ４５８のインスタンスを作成する。ユニットテストアダプタ４５８は、Ｃ＃関数として、または任意の他の適切な方法で実装することができる。テストアダプタ４５６は、ユニットテストアダプタ４５８のアクセサと見なすことができる。ユニットテストアダプタ４５８は、実行時に決定された特定のテスト４１６を呼び出すことによって特定のテスト対象ユニットに実行時バインドすることができる。実行時バインディングに必要な情報は、リフレクションを通じてまたは他の適切な方法でテスト４１６から得ることができる。

ユニットテストアダプタ４５８は、テストアダプタ４５６との通信が可能なインターフェース４８４を含んでいる。インターフェース４８４は、開発環境３１０で実行するプログラムが、公開されたインターフェース４８２を通じて通信できるので、開発環境３１０において公開される必要はない。

ユニットテストアダプタ４５８はテスト４１６を呼び出し、テスト４１６がホスト環境３２０で実行できるようにする。代替として、テスト関数は、ユニットテストアダプタ４５８に直接組み込むことができる。

ロードされて正しく構成されると、テスト４１６は実行することができる。テスト４１６は、ユニットテストアダプタ４５８によってロードし、実行できるＤＬＬモジュールにあってもよいが、任意の適切な形態を使用することができる。特定のコマンドおよびコンテキストデータは、開発環境３１０とホスト環境３２０の間の確立されているインターフェースを通じて提供することができる。結果は、インターフェース４３０を通じてエージェント４１０に戻すことができる。

開発環境とホスト環境のテスト対象ユニットとの間のインターフェースを提供する特定の方法は、ホスト環境の特性によって異なることがある。たとえば、ホスト環境がマイクロソフトＯｆｆｉｃｅアプリケーションスイートのアプリケーションである場合、テストターゲットとしてＷｅｂページを指定するのではなく、開発環境のテストアダプタによって送信されたテスト要求は、テスト対象ユニットを含む特定の文書を指定することができる。

単一のテストを実行するステップは、１つの例において行われる順序に１、２、．．．９と番号付けされている。ステップ１は、テスト実行シム４１２とやりとりしているエージェント４１０を表す。ステップ２は、テスト要求をホスト環境３２０に送信しているテスト実行シム４１２を表す。ステップ３は、ホストアダプタ４５４のインターフェースを登録するＨＴＴＰモジュール４５０を表す。ステップ４は、テスト実行シム４１２と、テスト実行シム４１２がテストアダプタ４５６のインターフェース４８２を通じて通信できるようにするホストアダプタ４５４との間の情報の交換を示す。ステップ５は、テスト実行シム４１２とテストアダプタ４５６の間の、テストを実行するために必要な情報の通信を表す。ステップ６は、テストを実行するプロセス内のテストアダプタ４５６とユニットテストアダプタ４５８との間の通信を示す。ステップ７は、ユニットテストアダプタ４５８とテスト４１６との間の通信を示す。テスト４１６は、それがどのように構成されるべきかについてのデータを含むことができる。さらに、データは、テストを実行する過程の間交換することができる。ステップ８は、テスト対象ユニット４６０をターゲットとするテストを構成するために必要な、テスト対象ユニット４６０からのテストアダプタ４５８によって取得された情報を示す。ステップ９は、開発環境においてテストの結果がエージェント４１０に送信されて戻されることを示す。ステップは、単一のテストの実行中のデータおよび制御の両方のフローの例を提供するために番号付けされている。実際の実装において、ステップは示されている順序で実行される必要はない。さらに、各々のステップは単一回数で行われる必要はない。たとえば、テストアダプタ４１４は、複数のインスタンスでコマンドまたはデータをテストアダプタ４５６に送信することもできる。

図４は、単一テスト４１６の実行を示している。実際のアプリケーションプログラムのテストにおいては、テストラン時に複数のテストを実行することができる。エージェント４１０は、テストラン時に多くのテストの起動を制御する可能性が高い。テストランにおける各テストは、各自のテスト実行シム４１２を使用することができる。テストラン全体に適用可能な属性またはその他の設定は、エージェント４１０において提供することができる。単一テストに適用可能な属性またはその他の設定は、テスト実行シム４１２、ユニットテストアダプタ４５８またはテスト４１６を通じて適用することができる。

たとえば、テストへの完全なＵＲＬがテストごとに指定される必要はない。むしろ、特定のマシンを指定する部分のようなＵＲＬのある部分をテスト環境において１度指定することができる。ＵＲＬへのそれ以降のすべての参照は、そのマシンを参照するように導くことができる。たとえば、特定のページを指定する部分のような、マシンに依存しない部分は、実行されるユニットテストごとに指定することができる。

図５は、前述のソフトウェア構成により可能になる開発環境のさらなる態様を示している。図５は、開発環境３１０でテストを開発している人間のプログラマが使用できるような、テストエディタへのインターフェース５００を示している。インターフェース５００は、人間のプログラマがテストプログラムを書いている場合の、文５１０のようなプログラム文を表示している。

インターフェース５００はさらに、本明細書においてポップアップウィンドウとして示されている、補足表示領域５１２を含んでいる。補足表示領域は、テストプログラムの作成中に人間のユーザーに関連する情報を表示するために使用することができる。この例では、補足表示領域５１２は、このテストプログラムのターゲットであるテスト対象ユニットにアクセスするために使用されるアクセサに関する情報を表示する。

たとえテストが作成される時点でテスト対象ユニットが定義されていない場合であっても、これにアクセスするために必要な情報は、図５に示すようにアクセサを通じて使用可能にすることができる。このようにして、インテリセンスのような機能は、開発環境において動作することができる。

説明される実施形態において、表示される特定の情報はコンテキストによって決まる。図５に示されている例では、人間のユーザーは命令５１０の部分をタイプ入力した。命令５１０は、コードアクセサ内の変数への部分参照を含んでいるが、これはテスト対象ユニットにアクセスするために使用することができる。命令のその部分は、タイプ入力された内容がコードアクセサ内で定義されている変数の名前によって完成される必要があることを識別するのに十分である。したがて、ポップアップウィンドウ５１２は、コードアクセサ内で定義される変数のリストを含んでいる。変数の完全名を入力するのではなく、ユーザーはポップアップウィンドウ５１２のリストから対象とする変数を選択することができる。リストから項目を選択することは、その項目の完全な識別子をタイプ入力するようユーザーに求める場合に比べてより簡単であり、エラーを生じる可能性も低くなる。

この手法は、変数の名前を単に表示することに限定されることはない。他のコンテキスト情報に関連して一部の命令が選択のセットを識別するのに十分な情報を提供する場合はいつでも、選択のリストが提示される。手法は、関数、インターフェース、またはプログラムで使用できるその他の構造体に適用することができる。選択肢のセットの識別および表示は、従来技術の場合と同様に行うことができる。ホスト環境においてテスト対象ユニットを実行する手法は、図５に表示されるタイプの情報を作成するために必要な情報を使用できるようにするアクセサの使用に適合する。

本発明の少なくとも１つの実施形態のいくつかの態様について説明してきたが、当業者にはさまざまな変更、修正、および改良が容易に考案されることを理解されたい。

たとえば、前述のソフトウェアアーキテクチャは、ホスト環境および開発環境が実行される特定のハードウェアアーキテクチャに依存しない。ホスト環境および開発環境は、同一のシングルプロセッサシステムまたはマルチプロセッサシステム上で実行することができる。「リモーティング」は、１つのコンピュータ上で異なるホストアプリケーションを実行することにより作成された異なる環境の間で行われることができ、別個の物理ロケーションのコンピュータ、サーバー、またはその他のプロセッサ上で実行するプロセス間で行われる必要はない。

さらに、図２から図４のような図は、開発環境またはホスト環境で実行するソフトウェアコンポーネントを示している。テストは、それがその環境内で使用可能なメソッド、プロパティ、およびその他のコンテキスト情報にアクセスできる場合に、ホスト環境で実行していると言われる。プログラムを作成または呼び出すために使用されるアプリケーションは、プログラムが実行する環境を指示する必要はない。

さらに、プログラムが実行するハードウェアは、その実行環境を決定づける必要はない。具体例として、ＰＤＡまたはスマートフォンなどの携帯型電子機器用のアプリケーションをテストすることが望ましい場合、ホスト環境と開発環境との間のすべての対話を．ＮＥＴリモーティングを通じて行う別個のリモートプラットフォームとしてホスト環境を扱うことが望ましい。代替として、エージェントおよびテストプログラムのすべてまたは一部を、実行する携帯型電子機器にロードすることが望ましい場合もある。

本明細書で使用されているように、テスト対象ユニットで通常は非パブリックであるメソッドおよび変数がアクセサプログラムを通じてリフレクションされることが説明される。さらに一般的には、テスト対象ユニットの任意のパラメータはリフレクションされうる。アクセサプログラムを通じてリフレクションすることができるパラメータの特性またはタイプは、特定のテスト対象ユニットまたはテストが作成されるプログラミング言語によって異なることがある。

テスト結果から作成される用途は、本発明を限定するものではない。テスト結果は、テスト対象ユニットのパフォーマンスの一部の態様に関するデータを提供することができる。パフォーマンス情報の特定のタイプは、特定のテストプログラムによって決まる。パフォーマンス情報は、ユニットが望ましい動作結果を提供するかどうかを示すことができる。代替として、パフォーマンス情報は、ユニットの実行時間に関する情報またはテストの実行中に使用された処理リソースに関する情報を提供することができる。

もう１つの例として、テスト対象ユニットにアクセスする特定のメソッドも、変更されうる。抽象化（ａｂｓｔｒａｃｔｉｏｎ）を使用することは必要ない。代替として、さらに多くの抽象化のレベルを使用することもできる。一例として、図４は、ユニットテストアダプタ４５８を通じてテストアダプタ４５６がテスト４１６にアクセスすることを示している。抽象化の追加のレベルは、ラッパーアラウンドテスト（ｗｒａｐｐｅｒ ａｒｏｕｎｄ ｔｅｓｔ）４１６を提供することなどにより、提供することができる。代替として、テストアダプタ４５６を直接にテスト４１６にアクセスさせることなどによって、より少ない抽象化のレベルを使用することもできる。

一般に、図で別個のブロックを含むように図示されているプログラムは、簡単にするためにこのような方法で示されている。複数のブロックによって示される関数は、単一の関数、Ｗｅｂページ、またはその他のプログラム要素に結合することができる。代替として、単一ブロックで実行するように示される関数は、複数のプログラム要素により実現することができる。前述の１つのブロックの関数が複数のプログラム要素により実現される場合、この集合体中のこれらのプログラム要素は、単一の機能ブロックであると見なすことができる。逆に、１つのプログラム要素が複数ブロックとして示されている関数を実現する場合、そのブロックは、任意のまたはすべての機能ブロックの実装と見なすことができる。

このような代替方法、変更、および改良は、本開示の一部となることを意図し、本発明の趣旨および範囲内にあることを意図する。したがって、上記の説明および図は、例示のために示されているに過ぎない。

本発明の前述の実施形態は、多数ある方法のどの方法でも実施することができる。たとえば、諸実施形態は、ハードウェア、ソフトウェア、またはこれらの組み合わせを使用して実施することができる。ソフトウェアで実施される場合、ソフトウェアコードは、単一コンピュータで提供されるかまたは複数コンピュータ間で分散されるかにはかかわりなく、任意の適切なプロセッサまたはプロセッサの集合で実行することができる。

さらに、本明細書において概説されているさまざまな方法またはプロセスは、各種のオペレーティングシステムまたはプラットフォームのいずれかを使用する１つまたは複数のプロセッサ上で実行可能なソフトウェアとしてコーディングすることができる。さらに、そのようなソフトウェアは、いくつかの適切なプログラミング言語および／または従来のプログラミングツールまたはスクリプトツールのいずれかを使用して作成することができ、さらに実行可能機械語コードとしてコンパイルすることができる。

この点において、本発明の１つの実施形態は、１つまたは複数のコンピュータまたはその他のプロセッサで実行されるとき、前述の本発明のさまざまな実施形態を実施する方法を実行する１つまたは複数のプログラムで符号化される（たとえばコンピュータメモリ、１つまたは複数のフロッピー（登録商標）ディスク、コンパクトディスク、光ディスク、磁気テープなどの）コンピュータ可読媒体（または複数のコンピュータ可読媒体）を対象としている。１つまたは複数のコンピュータ可読媒体は、そこに格納される１つまたは複数のプログラムが、１つまたは複数の異なるコンピュータまたはその他のプロセッサにロードされて前述の本発明のさまざまな態様を実施することができるように、移植可能にすることができる。

本明細書において「プログラム」という用語は一般的な意味で、コンピュータまたはその他のプロセッサをプログラムして前述の本発明のさまざまな態様を実施するために使用される任意のタイプのコンピュータコードまたは命令のセットを指すために使用される。さらに、本実施形態の１つの態様によれば、実行されるときに本発明の方法を実行する１つまたは複数のコンピュータプログラムが単一のコンピュータまたはプロセッサに存在する必要はなく、本発明のさまざまな態様を実施するために複数の異なるコンピュータまたはプロセッサ間にモジュラ方式で分散できることを理解されたい。

「パラメータ」、「オブジェクト」および「メソッド」などの用語もまた、一般的な意味で使用されている。一部のプログラミング言語は、値を関数に渡すことに関連して「パラメータ」を定義するが、本明細書においてこの用語は、一般的に情報の任意の部分を参照するために使用されている。同様に、一部のプログラミング言語は、特定のプログラミング構成体を参照するために「オブジェクト」および「メソッド」などの用語を使用する。特に明確に指示されていない限り、本明細書に使用されているそのような用語はそのような構成体のみに限定されることはない。

本発明のさまざまな態様は、単独で、組み合わせで、あるいは前述の実施形態で具体的には説明されていないさまざまな配置で使用することができるため、その適用は、上記の説明で示されているかまたは図に示されているコンポーネントの詳細および配置に限定されることはない。たとえば、ある実施形態で説明されている態様は、別の実施形態で説明されている態様といかなる形でも組み合わせることができる。

請求項において請求項の要素を変更するために「第１の」、「第２の」、「第３の」などの順序を示す用語を使用することはそれだけで、ある請求項の要素の別の要素に対する優先度、優先順位、または順序を、あるいは方法の動作が実行される時間的な順序を暗示するものではないが、特定の名前を持つある請求項の要素と、同じ名前を持つ（順序を示す用語の使用を除いて）別の要素とを区別するためのラベルとして使用されているに過ぎない。

さらに、本明細書において使用される表現法および用語は説明を目的としており、限定的なものと見なされるべきではない。本明細書において、「含む（ｉｎｃｌｕｄｉｎｇ）」、「含む、備える（ｃｏｍｐｒｉｓｉｎｇ）」、または「有する（ｈａｖｉｎｇ）」、「含む（ｉｎｖｏｌｖｉｎｇ）」、およびその変形の使用は、それ以降に記載される項目とその等価物および追加の項目を包含することを意図している。

コンピュータプログラムリスト
ＡＳＰ．ＮＥＴで実行するように構成されたテストのサンプルを以下に示す。

ホストアダプタの実装のための擬似コードの例を以下に示す。

テスト実行シムは、以下の形式のインターフェースを通じてそのようなホストアダプタと通信することができる。

クラスがテスト対象ユニットに実行時バインドするときにアクセサを作成するために使用できる単純なアクセサクラス定義の例を以下に示す。

従来技術におけるブラックボックステストを示す概略図である。 従来技術におけるユニットテストを示す概略図である。 本発明の実施形態によるユニットテストを示す概略図である。 本発明の代替実施形態によるユニットテストを示す概略図である。 本発明のもう１つの実施形態によるユニットテストを示す概略図である。 本発明のもう１つの実施形態によるユニットテストを示す概略図である。 本発明の一実施形態によるユーザーインターフェースを示す概略図である。

符号の説明

１１０，３１０ 開発環境
１１２，３１２，４１０ エージェント
１２０，３２０ ホスト環境
１２４ パブリック
２１４，３３０，４１６ テストＡ
２２６，４６０ テスト対象ユニット
３１４，４１２ テスト実行シム
１２２ パブリック
３２２，４５４ ホストアダプタ
４５０ Ｈｔｔｐモジュール
４５６ テストアダプタ
４５８ ユニットテストアダプタ

Claims (20)

1. 第１の環境において動作するプログラムをテストする方法であって、前記プログラムは少なくとも１つのテスト対象ユニットを含む複数のユニットを有し、
   ａ）第２の環境においてテストエージェントを実行するステップであって、前記テストエージェントは少なくとも１つのテスト対象ユニットをテストするために実行されるテストを指定するステップと、
   ｂ）前記テストエージェントの実行に応答して、前記第１の環境において、指定されたテストを実行するステップであって、前記テストはテスト対象ユニットのパフォーマンス特性を示すテスト結果を生成するステップとを備えることを特徴とする方法。
2. 前記第１の環境において実行する前記指定されたテストから前記第２の環境において実行する前記テストエージェントにテスト結果を伝達するステップをさらに備えることを特徴とする請求項１に記載の方法。
3. 前記第１の環境において、指定されたテストを実行するステップは、前記第１の環境においてオブジェクトを作成するステップ、および前記オブジェクトを前記第２の環境のオブジェクトに登録するステップを含むことを特徴とする請求項２に記載の方法。
4. 指定されたテストを実行するステップは、
   ａ）前記第１の環境においてテストオブジェクトを実行するステップと、
   ｂ）前記第２の環境の前記オブジェクトと前記テストオブジェクトとの間で前記第１の環境の前記オブジェクトを通じて通信するステップとをさらに備えることを特徴とする請求項３に記載の方法。
5. 指定されたテストを実行するステップは、前記第１の環境においてテストアダプタを実行するステップと、前記テストアダプタを使って前記指定されたテストを呼び出すステップとを含むことを特徴とする請求項２に記載の方法。
6. 指定されたテストを実行するステップは、前記テストアダプタを使って前記指定されたテストを示すパラメータを受け取るステップと、前記パラメータに応じて選択されたテストを呼び出すステップとをさらに備えることを特徴とする請求項５に記載の方法。
7. 前記第１の環境は、拡張可能インターフェースを備え、テストアダプタを実行するステップは、前記拡張可能インターフェースを通じて提供されるコマンドに応答してテストアダプタを前記第１の環境において実行するステップを備えることを特徴とする請求項５に記載の方法。
8. 前記テスト対象ユニットは非パブリックインターフェースを有し、指定されたテストを実行するステップは、その非パブリックインターフェースを通じて前記テスト対象ユニットを実行するステップを備えることを特徴とする請求項１に記載の方法。
9. 第１の環境において動作するプログラムをテストする方法であって、前記プログラムはユニットの少なくとも１つがテスト対象ユニットである複数のユニットを有し、
   ａ）前記第１の環境に前記プログラムをロードするステップと、
   ｂ）前記第１の環境においてオブジェクトのインターフェースを公開するステップと、
   ｃ）前記インターフェースを通じて提供される情報に応じてテストアダプタをロードするために前記オブジェクトを使用するステップと、
   ｄ）少なくとも１つのテスト対象ユニットのテストを実行するためにテストアダプタを使用するステップとを備えることを特徴とする方法。
10. 前記第２の環境において実行するテストエージェントの実行に応答して前記インターフェースを通じて情報を提供するステップをさらに備えることを特徴とする請求項９に記載の方法。
11. 第２の環境においてテストエージェントの実行に応答して情報を提供するステップは、開発環境において前記テストエージェントを実行するステップを備えることを特徴とする請求項１０に記載の方法。
12. 第２の環境において実行するテストエージェントの実行に応答して前記インターフェースを通じて情報を提供するステップは、前記第１の環境の属性に基づいてテスト実行シムを選択するステップと前記テスト実行シムを通じて前記インターフェースにアクセスするステップとを備えることを特徴とする請求項１０に記載の方法。
13. 前記第１の環境をテストモードに置くステップをさらに備えることを特徴とする請求項９に記載の方法。
14. 前記第１の環境において前記プログラムをロードするステップは、アプリケーションプログラムにアドインプログラムをロードするステップを備えることを特徴とする請求項９に記載の方法。
15. 前記第１の環境は第１のプロセスに作成され、前記第２の環境は第２のプロセスに作成されることを特徴とする請求項１０に記載の方法。
16. ａ）前記第１の環境においてユニットのパラメータをリフレクションするステップと、
    ｂ）前記テストアダプタを構成するために前記リフレクションされたパラメータを使用するステップとをさらに備えることを特徴とする請求項９に記載の方法。
17. 複数のホスト環境の１つにおいて動作するプログラムのユニットをテストするためにテストプログラムが開発される開発環境を提供するソフトウェアシステムを実施するステップを実行するためのコンピュータ実行可能命令を有するコンピュータ可読媒体であって、前記コンピュータ実行可能命令は、
    ａ）テストエージェントを作成するステップと、
    ｂ）複数のホストアダプタの１つを作成するステップであって、各ホストアダプタは、複数のホスト環境の１つにおいてテストプログラムの実行を呼び出すために前記テストエージェントによって使用されるように構成されるステップとを実行することを特徴とするコンピュータ可読媒体。
18. 前記ソフトウェアシステムは、
    ａ）テストプログラムの命令の一部を指定するユーザーから入力を受け取るステップと、
    ｂ）前記プログラムのユニットにアクセスするために前記テストプログラムの前記命令で使用されるパラメータに関するコンテキストに応じた情報をユーザーからの入力に応答して選択的に表示するステップとを実行するコンピュータ実行可能命令をさらに備えることを特徴とする請求項１７に記載のコンピュータ可読媒体。
19. 前記ソフトウェアシステムは、前記ユニットからリフレクションされた前記プログラムの前記ユニットに関連するパラメータを受け取るステップを実施するコンピュータ実行可能命令をさらに備えることを特徴とする請求項１８に記載のコンピュータ可読媒体。
20. 前記ソフトウェアシステムは、前記ユニットからリフレクションされた前記プログラムの前記ユニットに関する情報に基づいてテストプログラムを構成するオブジェクトを作成するコンピュータ実行可能命令をさらに備えることを特徴とする請求項１７に記載のコンピュータ可読媒体。
    

Images