1

OpenWrap 2.0 のベータ版を使用しています。OpenWrap には、単体テストを実行するためのサポートが含まれています。私の質問は、これがどのように機能するのかということです。

ビルドされたラップを取得し、ラップに含まれるテストを検索して実行しようとするテストランナーと見なす必要がありますか? ラップ内にテストを含める必要はありますか?

依存関係の解決は、テストのコンテキストでどのように機能しますか? テストに必要な追加の依存関係を追加する tests-scope を指定できます。それらの依存関係はいつ使用されますか? テストプロジェクトをビルドし、テストラップでテストを実行するために使用されると思いますか? ただし、ラップにテストを含める場合、それらのテストスコープの依存関係もラップの依存関係と見なすべきではありませんか、または「テストラップ」を実行しようとしたときにのみ依存関係として使用されますか?

テストのコンテキストで私が疑問に思っていたもう 1 つのことは、コンパイル時と実行時の依存関係の違いです。

例として、API を指定するプロジェクト API があります。そのプロジェクトの隣に、それぞれがその API の異なる実装を指定する 2 つのプロジェクト Impl1 と Impl2 があります。その隣には、API に対するテストを含むテスト プロジェクト API.Tests があります。テストは、依存性注入を使用して Impl1 または Impl2 のいずれかを注入し、テストを実行します。この場合、API.Tests プロジェクトは、API に対するコンパイル時の依存関係のみを持ちます (コンパイル時の依存関係としてのみ利用可能にする必要があります)。ただし、テストを実行すると、プロジェクトは Impl1 または Impl2 に実行時依存します。これをパッケージ化する方法について何か提案はありますか?

4

1 に答える 1

0

test-wrap は、パッケージ (/tests 内) の一部として出荷されているテストのテスト ランナーを実行できます。

現在の実装は最新ではありません。主な理由は、パッケージに testdriven.net テスト ランナーが含まれておらず、これらのテストの実行がかなり複雑になっているためです。この理由により、私はまだこの計画を再評価していません。

OpenWrap 2 はスコープを使用して、コードの特定のサブセットにのみ適用される依存関係を定義します。テストの場合、記述子に正しい辞書構造命令がある場合、プロジェクトは正しいスコープでそれらの依存関係を取り込みます。

つまり、その情報をアセンブリに保持しないため、これらのテストを実行するときに、テスト スコープの依存関係をロードしません。これはおそらく (少なくともテストに対しては) 実行する必要があります。ただし、パッケージ内のすべてのアセンブリは現在の appdomain に挿入されるため、シナリオでは、テストが /tests にある場合、それらすべてのアセンブリを同じパッケージにパッケージ化するだけで機能します。

同じメカニズムが

于 2011-10-31T15:53:26.597 に答える