2

一般的な目標

CI の目的で、(コマンドライン経由で) ヘッドレス ソリューション全体ですべてのテストを実行する PowerShell スクリプトを作成しようとしています。個別に実行できる UnitTests と IntegrationTests があります。

ソリューション構造

このソリューションは、Visual Studio 2013 ソリューションです (Professional バージョンを使用)。すべてのプロジェクトには、必要に応じて、テスト用に 1 つまたは 2 つの個別のプロジェクトがあります。1 つのプロジェクトは単体テスト用で、もう 1 つのプロジェクトは統合テスト用です。簡単な命名規則に従います。

  • コンポーネント: Namespace.ComponentName
  • 単体テスト: Namespace.ComponentName.Test
  • Int。test : Namespace.ComponentName.IntegrationTest

テスト ツール

VSTest.Console.exe を使用してテストを実行しています。

現在失敗しているソリューション

または単体テストのみ、または統合テストのみを実行しようとしています。そのため、すべてのテスト dll ファイルをスキャンし、それらをサフィックスでフィルター処理するというアイデアがありました。

単体テストの例:

# Declare my parameter that will contain the targeted TestFileNames
$Parameters = '';

# Get all the test project names, space separated that match *.Test.dll in my solution
Get-ChildItem $RepositoryRootLocation -Filter *.Test.dll -Recurse | ? {$_.fullname -notmatch 'obj'} | % { $Parameters =  $Parameters + $_.FullName+ " "};

#Run the VSTest.Console.Exe with the specified test project names
& $MsTestConsolePath $Parameters ;

これは正常に動作するはずです。唯一の問題は、ネストされたサブフォルダーに 40 以上のテスト プロジェクトがあることです。これにより、このスクリプトを実行すると例外が発生します:

Get-ChildItem : The specified path, file name, or both are too long. The    fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.

メッセージは自明なので、問題は、いくつかの厄介な単純な制限にぶつかっているため、この問題は拡張可能ではないということです。

主な質問

フィルターに基づいてテスト プロジェクトの特定のサブセットのみを実行できる VSTest.Console.exe を使用する別の方法はありますか?

問題に取り組むために別の角度から取り組まなければなりませんか? または、すべてのテスト プロジェクトがソリューション リポジトリのサブフォルダーにある場合、完全なファイル パスではなく、テスト プロジェクト名のみを使用できますか?

重要: 簡単に拡張できるはずなので、新しく作成されたすべてのテスト プロジェクトでこれを testsettings ファイルなどに追加する必要はありません。ソリューション内のすべてのテスト プロジェクトを実行し、ユニット タイプまたは統合タイプであるかどうかをフィルタリングできるようにしたいと考えています。

テスト プロジェクト名のフル パス名を短縮するためにディスクのルートにリポジトリを配置することは、スクリプトが任意のマシンで実行される可能性があるため、柔軟ではありません。

4

1 に答える 1

1

私はいくつかのことを試してみます。

まず、ビルド サーバーのパスをドライブのルートにあるフォルダーに変更します。フォルダーが少ないほど、「パスが長すぎる」問題が発生する可能性が低くなります。
パスを短くすることは適切な解決策ではないかもしれないと言いますが、そうです。ビルド マシンに要件を設定することもできます (たとえば、「.net をインストールする」がその 1 つです)。

次に、プロジェクトの出力パスを別のフォルダーに変更できます。たとえば、ソリューションのルートに「bin」フォルダーを作成し、「debug」、「release」、および「test」サブフォルダーを作成します。
次に、プロジェクトのタイプと構成に応じて、ルートでバイナリを出力するようにプロジェクトを構成します (通常のプロジェクトは bin\debug|release に、テスト プロジェクトはデバッグまたはリリースに関係なく bin\test に)。
このように「新しく作成された各テスト プロジェクト」を構成したくないかもしれませんが、現実的には、ソリューションがもう少し安定したら、いくつの新しいプロジェクトを作成しますか?

プロジェクトのパスを構成することは、一般的な DevOps/継続的インテグレーション タスクです。自分をだまさないでください。過度に賢くなろうとしないでください。また、ビルド スクリプトがどのような場合でもどこでも実行されると想定しないでください。プロジェクトに何らかの複雑さがある場合 (外部依存関係に依存する場合)、「これとあれをインストールする」などのビルド要件を定義する必要があります。そのため、「ディスク ルートから最大で 2 または 3 フォルダーの深さのソースを持たない」のはなぜですか? .

于 2015-06-25T09:36:06.990 に答える