8

SpecFlow、NUnit、Coypuを使用してWebアプリケーションの受け入れテストを行うプロジェクトがあります。ビルドサーバーでJenkinsを介してプロジェクトのビルドに問題はありません。Jenkinsはspecsプロジェクトでmsbuildを実行するpsakeスクリプトを呼び出し、次にスクリプトはnunit-consoleを呼び出してspecs / testsを実行し、SpecFlowからレポートを生成したいと思います。

Framework "4.0"

task Default -depends RunSpecs

task BuildSpecs {
    $env:EnableNuGetPackageRestore = "true"
    msbuild /t:Rebuild ReturnsPortal.Specs.csproj
}

task RunSpecs -depends BuildSpecs {
    exec { & "C:\path\to\NUnit 2.5.9\bin\net-2.0\nunit-console-x86.exe" /labels /out=TestResult.txt /xml=TestResult.xml .\bin\Debug\TheWebApp.Specs.dll }
    exec { & "C:\path\to\SpecFlow\1.8.1\specflow.exe" nunitexecutionreport TheWebApp.Specs.csproj /out:SpecResult.html }
}

ただし、specflow.exeへの最後のexec呼び出しは失敗し、次のようになります。

要素<UsingTask>の下の要素<ParameterGroup>は認識されません。C：\ Program Files（x86）\ Jenkins \ jobs \ TheWebApp \ worksheet \ Web \ Sites \ TheWebApp.nuget \ nuget.targets

少しグーグルすると、使用されているmsbuildバージョンに問題がある可能性があります（たとえば、ここ、ここ）。しかしFramework "4.0"、私はpsakeスクリプトを使用しており、Specsプロジェクトは.NET Framework 4.0を対象としており、ビルドステップで正常にビルドされるため、specflowが以前のバージョンのmsbuildを使用しているように見える理由がわかりません。それともどこか別の問題ですか？

4

2 に答える 2

30

これは、SpecFlowWikiからの私にとっての答えでした。

.NET 4.0プロジェクトにとって重要：specflow.exeは.NET 3.5用にコンパイルされているため、デフォルトでは.NET4.0アセンブリをロードできません。.NET 4.0プロジェクトのこのレポートを生成するには、構成ファイルを使用して、specflow.exeに.NET4.0ランタイムの使用を強制する必要があります。以下の構成をコピーしてspecflow.exe.configファイルを作成し、specflow.exeの横に配置するだけで、ステップ定義レポートを作成できます。

<?xml version="1.0" encoding="utf-8" ?> 
<configuration> 
    <startup> 
        <supportedRuntime version="v4.0.30319" /> 
    </startup> 
</configuration>
于 2012-07-11T10:44:41.817 に答える
2

上記で提案した設定ファイルソリューションを使用しようとしました。ローカルでのテストには機能しましたが、コードをCI環境にプッシュするとすぐに、CI環境にその構成ファイルがないため、コードがチョークされました。さまざまなパッケージのクリーンバージョンのみを使用するようにCI環境を制限しているため、CIサーバーに特別な構成を挿入しようとはしませんでした。

SpecFlowは、特別な構成ファイルがなくても、いくつかの.NET4.0プロジェクトで問題なく動作することに気づきました。少し調べてみると、実際の「問題」はNuGet2.1のようです。NuGet1.7を使用する.NET4.0プロジェクトでは、すべてが正常に機能します。

1.7〜2.1のどこかで、NuGetはNuGet.targetsファイルに、古いバージョンのMSBuildではサポートされていない新機能を導入しました。具体的には、エラーメッセージで説明されているように、問題は<ParameterGroup>下の要素にあるようです。<UsingTask>

ターゲットファイルをざっと見ると、セクションがNuGetを最新の状態に保つ責任があることがわかります。このセクションを削除すると、上記の構成ファイルを追加するのと同じ方法で問題が完全に解決されますが、提供されていると思われる自己更新機能も削除されます。.targetsファイルがリポジトリにコミットされている場合、このソリューションはCI環境でも機能し、CI側で変更を加える必要はありません。

これは必ずしもngmよりも優れたソリューションではなく、単なる別のソリューションです。環境によっては、これが望ましい方法である場合とそうでない場合があります。

于 2013-01-10T22:28:10.787 に答える