Wie führen Sie NUnit-Tests von Jenkins aus?

Ich möchte jeden Abend und bei jedem Commit für svn automatisierte NUnit-Tests für eine C # -Anwendung ausführen.

Kann Jenkins-CI das?
Gibt es ein Online-Tutorial oder eine Anleitung, die ein ähnliches Setup dokumentiert, das ich mir ansehen kann?

Ich musste genau das tun, was Sie tun. So richte ich Jenkins ein:

1. Fügen Sie das NUnit Plugin zu Jenkins hinzu
2. Gehen Sie in Ihrem Projekt zu Konfigurieren -> Erstellen -> Build-Schritt hinzufügen
3. Scrollen Sie in der Dropdown-Liste nach unten zu -> Windows- Stapelbefehl ausführen
4. Stellen Sie sicher, dass dieser Schritt nach Ihrem MSBuild-Schritt platziert ist
5. Fügen Sie Folgendes hinzu und ersetzen Sie die Variablen:

Einzelner DLL-Test:

[PathToNUnit] \ bin \ nunit-console.exe [PathToTestDll] \ Selenium.Tests.dll /xml=nunit-result.xml

Mehrfach-DLL-Test mit NUnit-Testprojekten :

[PathToNUnit] \ bin \ nunit-console.exe [PathToTests] \ Selenium.Tests.nunit /xml=nunit-result.xml

1. Unter Post-Build - Aktionen , tick Publish Ergebnis NUnit Testbericht
2. Für die Textbox Prüfbericht XMLs , geben Sie nunit-result.xml

Sobald Ihr Projekt erstellt wurde, wird NUNit ausgeführt und die Ergebnisse können entweder im Dashboard (wenn Sie den Mauszeiger über das Wetterberichtsymbol bewegen) oder auf der Projektseite unter Letztes Testergebnis angezeigt werden .

Sie können den Befehl auch in Visual Studio oder als Teil Ihres lokalen Erstellungsprozesses ausführen.

Hier sind zwei Blog-Beiträge, die ich als Referenz verwendet habe. Ich habe keine gefunden, die genau meinen Anforderungen entsprach:
1-stündiger Leitfaden zur Einrichtung der kontinuierlichen Integration: Jenkins erfüllt .Net (2011)
Leitfaden zum Erstellen von .NET-Projekten mit Hudson (2008)

Wenn Sie Ihre Unit-Test-Projekte nicht fest codieren möchten, schreiben Sie besser ein Skript, um alle DLLs Ihrer Unit-Test-Projekte abzurufen. Wir machen das mit Powershell und befolgen eine spezielle Konvention für die Benennung unserer Unit-Testing-Projekte. Hier ist der Inhalt der Powershell-Datei, die unsere Unit-Tests ausführt:

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

Das Skript ist robust genug, dass wir es für alle Build-Jobs wiederverwenden. Wenn Ihnen der vollständige Pfad zur NUnit-Konsole nicht gefällt, können Sie diesen Speicherort jederzeit in Ihre Umgebungsvariable PATH einfügen.

Dann legen wir die Datei RunUnitTests.ps1 auf unserem Build-Server ab und verwenden diesen Batch-Befehl:

powershell.exe -file "{full-path-to-script-direcory}\RunUnitTests.ps1"

Für Nunit 3 oder höher:

1. Erstellungsschritt (Windows-Befehlszeile) "c:\Program Files (x86)\NUnit.org\nunit-console\nunit3-console.exe" c:\AutomationTraining\CSharpSelenium\bin\Debug\test.dll --result=TestR.xml;format=nunit2

2. Nach dem Schritt für die Veröffentlichung des Nunit-Berichts wird nur die Testergebnisdatei im Jenkins-Arbeitsbereichsverzeichnis angezeigt , nicht in Ihrem Projekt: TestR.xml

Wir müssen Testergebnisse im Nunit2-Format erstellen, da das Jenkins Nunit-Plugin das Nunit3-Ergebnisformat jetzt nicht erkennt. Auch das Format der --result=TestR.xml;format=nunit2 Optionszeichenfolge ist unterschiedlich: NICHT /xml=nunit-result.xml

Das funktioniert gut, ich habe das schon einmal eingerichtet.

Konfigurieren Sie NUnit so, dass die Ergebnisse in eine XML-Datei ausgegeben werden, und konfigurieren Sie das NUnit Jenkins-Plugin so, dass diese XML-Datei verwendet wird. Die Ergebnisse werden im Dashboard verfügbar sein.

Nun liegt es an Ihnen, wie Sie NUnit aufrufen. So haben wir es gemacht: Jenkins Job führt NAnt-Ziel aus NUnit-Testsuite.

Sie können Jenkins-Jobs so konfigurieren, dass sie beim Festschreiben ausgeführt und / oder zu einem bestimmten Zeitpunkt geplant werden.

Die Lösung von Ralph Willgoss funktioniert gut, aber ich habe zwei Dinge geändert, um sie großartig zu machen:

a) Ich habe ein NUnit-Projekt anstelle der DLL-Datei direkt verwendet. Dies erleichtert das Hinzufügen weiterer Assemblys oder das Konfigurieren des Tests in der NUnit-GUI.

b) Ich habe dem Stapel eine weitere Zeile hinzugefügt, um zu verhindern, dass der Build fehlschlägt, wenn ein Test fehlschlägt:

[PathToNUnit]\bin\nunit-console.exe [PathToTestProject]\UnitTests.nunit /xml=nunit-result.xm
exit 0

Das erwähnte NUnit Plugin markiert den Build automatisch als UNSTABLE , was genau das ist, was ich will, wenn ein Test fehlschlägt. Es zeigt mit einem gelben Punkt.

Ich denke, es ist besser, den Build zu scheitern, wenn er nicht erfolgreich ist, damit Sie ihn nicht bereitstellen. Mach so etwas:

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%

Referenz: http://www.greengingerwine.com/index.php/2013/01/tip-check-errorlevel-in-your-post-build-steps-when-using-nunit/

Jenkins hat Plugins, die das unterstützen. Die genaue Konfiguration hängt stark von Ihrem Projekt-Setup ab. Es gibt spezielle Plugins für nUnit, MSBuild, nAnt usw. Schauen Sie sich zunächst die Plugins-Seite an, aber es sollte nicht besonders schwierig sein, dies herauszufinden.

Dies ist meine Lösung zum Ausführen von OpenCover mit vstest in Jenkins:

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

Jede Test-DLL wird in einem eigenen Prozess ausgeführt, da wir Probleme hatten, alle Test-DLLs in einem einzigen Prozess auszuführen (Probleme beim Laden von Assemblys).

Für .Net Core reicht es aus, den Build-Schritt "Shell ausführen" mit folgendem Skript hinzuzufügen:

#!bash -x

cd $my_project_dir
rm -rf TestResults   # Remove old test results.
dotnet test -l trx

Fügen Sie anschließend die Post-Build-Aktion "MSTest-Testergebnisbericht veröffentlichen" hinzu, um die Testergebnisse sichtbar zu machen.

Der Standardpfad für Testberichte sollte **/*.trxund wird alle erstellten .trxDateien veröffentlichen.