私は、C#アプリケーションの自動化されたNUnitテストを毎晩、svnにコミットするたびに実行したいと考えています。
これはジェンキンスCIができることですか?
私が見ることができる同様のセットアップを文書化したオンラインチュートリアルまたはハウツー文書はありますか?
私はあなたがすることを正確に行う必要がありました、これを行うためにジェンキンスを設定する方法は次のとおりです:
単一のdllテスト:
[PathToNUnit]\bin\nunit-console.exe [PathToTestDll]\Selenium.Tests.dll /xml=nunit-result.xml
NUnitテストプロジェクト :を使用した複数のdllテスト
[PathToNUnit]\bin\nunit-console.exe [PathToTests]\Selenium.Tests.nunit /xml=nunit-result.xml
プロジェクトをビルドすると、NUNitが実行され、結果がダッシュボード(天気予報アイコンにカーソルを合わせた場合)またはプロジェクトページLast Test Result。
Visual Studio内から、またはローカルビルドプロセスの一部としてコマンドを実行することもできます。
これは、参考のために使用した2つのブログ投稿です。私の要件にぴったり合ったものは見つかりませんでした:
継続的インテグレーション設定の1時間ガイド:Jenkins meets .Net (2011)
ハドソンを使用した.NETプロジェクトの構築ガイド (2008)
ユニットテストプロジェクトをハードコードしたくない場合は、ユニットテストプロジェクトのdllをすべて取得するスクリプトを作成する方が良いでしょう。私たちはPowershellでそれを行い、ユニットテストプロジェクトの命名に関する特定の規則に従います。ユニットテストを実行するpowershellファイルの内容は次のとおりです。
param(
[string] $sourceDirectory = $env:WORKSPACE
, $fileFilters = @("*.UnitTests.dll", "*_UnitTests.dll", "*UnitTests.dll")
, [string]$filterText = "*\bin\Debug*"
)
#script that executes all unit tests available.
$nUnitLog = Join-Path $sourceDirectory "UnitTestResults.txt"
$nUnitErrorLog = Join-Path $sourceDirectory "UnitTestErrors.txt"
Write-Host "Source: $sourceDirectory"
Write-Host "NUnit Results: $nUnitLog"
Write-Host "NUnit Error Log: $nUnitErrorLog"
Write-Host "File Filters: $fileFilters"
Write-Host "Filter Text: $filterText"
$cFiles = ""
$nUnitExecutable = "C:\Program Files (x86)\NUnit 2.6.3\bin\nunit-console-x86.exe"
# look through all subdirectories of the source folder and get any unit test assemblies. To avoid duplicates, only use the assemblies in the Debug folder
[array]$files = get-childitem $sourceDirectory -include $fileFilters -recurse | select -expand FullName | where {$_ -like $filterText}
foreach ($file in $files)
{
$cFiles = $cFiles + $file + " "
}
# set all arguments and execute the unit console
$argumentList = @("$cFiles", "/framework:net-4.5", "/xml=UnitTestResults.xml")
$unitTestProcess = start-process -filepath $nUnitExecutable -argumentlist $argumentList -wait -nonewwindow -passthru -RedirectStandardOutput $nUnitLog -RedirectStandardError $nUnitErrorLog
if ($unitTestProcess.ExitCode -ne 0)
{
"Unit Test Process Exit Code: " + $unitTestProcess.ExitCode
"See $nUnitLog for more information or $nUnitErrorLog for any possible errors."
"Errors from NUnit Log File ($nUnitLog):"
Get-Content $nUnitLog | Write-Host
}
$exitCode = $unitTestProcess.ExitCode
exit $exitCode
このスクリプトは十分に堅牢であるため、すべてのビルドジョブで再利用できます。 NUnitコンソールへのフルパスが気に入らない場合は、常にその場所をPATH環境変数に入れることができます。
次に、ビルドサーバーにRunUnitTests.ps1ファイルを配置し、次のバッチコマンドを使用します。
powershell.exe -file "{full-path-to-script-direcory}\RunUnitTests.ps1"
Nunit 3以上の農作業の場合:
構築ステップ(Windowsコマンドライン)"c:\Program Files (x86)\NUnit.org\nunit-console\nunit3-console.exe" c:\AutomationTraining\CSharpSelenium\bin\Debug\test.dll --result=TestR.xml;format=nunit2
Nunitレポート発行のステップ後、プロジェクトではなく、Jenkinsワークスペースディレクトリのテスト結果ファイルのみを表示します。TestR.xml
Jenkins NunitプラグインがNunit3結果形式を認識しないため、nunit2形式でテスト結果を作成する必要があります。オプションの文字列形式も異なります:--result=TestR.xml;format=nunit2
NOT /xml=nunit-result.xml
これはうまく機能します。以前に設定しました。
結果をXMLファイルに出力するようにNUnitを構成し、このXMLファイルを使用するように NUnit Jenkinsプラグイン を構成します。結果はダッシュボードで利用可能になります。
さて、NUnitを呼び出す方法はあなた次第です。その方法は次のとおりです。JenkinsジョブはNAntターゲットを実行し、NUnitテストスイートを実行します。
Jenkinsジョブは、特定の時間にコミットまたはスケジュール、あるいはその両方で実行するように構成できます。
Ralph Willgossのソリューションは正常に機能していますが、2つの点を変更して改善しました。
a)DLLファイルの代わりにNUnitプロジェクトを直接使用しました。これにより、さらに簡単にアセンブリを追加したり、NUnit GUIでテストを構成したりできます。
b)テストが失敗したときにビルドが失敗しないように、バッチにもう1行追加しました。
[PathToNUnit]\bin\nunit-console.exe [PathToTestProject]\UnitTests.nunit /xml=nunit-result.xm
exit 0
上記のNUnitプラグインはビルドをマークしますUNSTABLEこれは、テストが失敗するたびに、まさに私が望むものです。黄色の点で表示されます。
ビルドが成功しない場合、ビルドを失敗させて展開しない方が良いと思います。このようなことをしてください:
C:\YourNUnitDir\nunit-console.exe C:\YourOutDir\YourLib.dll /noshadow
if defined ERRORLEVEL if %ERRORLEVEL% neq 0 goto fail_build
:: any other command
: fail_build
endlocal
exit %ERRORLEVEL%
これは、ジェンキンスでOpenCover with vstestを実行するための私のソリューションです:
param(
[string] $sourceDirectory = $env:WORKSPACE
, $includedFiles = @("*Test.dll")
, $excludedFiles = @("*.IGNORE.dll")
, [string]$filterFolder = "*\bin\Debug*"
)
# Executables
$openCoverExecutable = "C:\Users\tfsbuild\AppData\Local\Apps\OpenCover\OpenCover.Console.exe"
$unitExecutable = "F:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe"
# Logs
$openCoverReport = Join-Path $sourceDirectory "opencover.xml"
$openCoverFilter = "+[*]* -[*Test]*"
Write-Host "`r`n==== Configuration for executing tests ===="
Write-Host "Source: `"$sourceDirectory`""
Write-Host "Included files: `"$includedFiles`""
Write-Host "Excluded files: `"$excludedFiles`""
Write-Host "Folder filter: `"$filterFolder`""
Write-Host ""
Write-Host "OpenCover Report: `"$openCoverReport`""
Write-Host "OpenCover filter: `"$openCoverFilter`""
# look through all subdirectories of the source folder and get any unit test assemblies. To avoid duplicates, only use the assemblies in the Debug folder
[array]$files = get-childitem $sourceDirectory -include $includedFiles -exclude $excludedFiles -recurse | select -expand FullName | where {$_ -like $filterFolder} | Resolve-Path -Relative
$exitCode = 0
$failedTestDlls = ""
foreach ($file in $files)
{
Write-Host "`r`nCurrent test dll: $file"
# set all arguments and execute OpenCover
$argumentList = @("-target:`"$unitExecutable`"", "-targetargs:`"$file /UseVsixExtensions:false /Logger:trx`"", "-register:user -filter:`"$openCoverFilter`" -mergeoutput -mergebyhash -skipautoprops -returntargetcode -output:`"$openCoverReport`"")
$unitTestProcess = start-process -filepath $openCoverExecutable -argumentlist $argumentList -wait -nonewwindow -passthru -WorkingDirectory $sourceDirectory
if ($unitTestProcess.ExitCode -ne 0)
{
$failedTestDlls = $failedTestDlls + $file + "`r`n"
$exitCode = $unitTestProcess.ExitCode
}
}
if ($exitCode -ne 0)
{
Write-Host "`r`n==== Executing tests in following dlls failed ===="
Write-Host "$failedTestDlls"
}
exit $exitCode
すべてのテストdllを単一のプロセス(アセンブリの読み込みを伴う問題)で実行するのに問題があったため、各テストdllは独自のプロセスで実行されます。
Jenkinsには、それをサポートするプラグインがあります。正確な構成は、プロジェクトのセットアップにかなり依存します。 nUnit、MSBuild、nAntなどの特定のプラグインがあります。プラグインのページを確認することから始めますが、理解するのはそれほど難しくないはずです。
.Net Coreの場合、次のスクリプトを使用して「シェルの実行」ビルドステップを追加するだけで十分です。
#!bash -x
cd $my_project_dir
rm -rf TestResults # Remove old test results.
dotnet test -l trx
その後、「MSTestテスト結果レポートの発行」ビルド後アクションを追加して、テスト結果を表示します。
デフォルトのテストレポートパスは**/*.trx
である必要があり、生成されたすべての.trx
ファイルを公開します。