Come si eseguono i test NUnit da Jenkins?

Sto cercando di eseguire test NUnit automatizzati per un'applicazione C #, ogni notte e su ogni commit su svn.

È qualcosa che Jenkins-CI può fare?
Esiste un tutorial online o una procedura per documentare che documenta una configurazione simile che posso guardare?

Avevo bisogno di fare esattamente quello che fai, ecco come ho configurato Jenkins per farlo:

1. Aggiungi il plugin NUnit a Jenkins
2. Nel tuo progetto vai a Configura -> Costruisci -> Aggiungi un passaggio di compilazione
3. Nel menu a discesa scorri verso il basso fino a -> Esegui comando batch di Windows
4. Assicurati che questo passaggio sia posizionato dopo il passaggio di MSBuild
5. Aggiungere quanto segue, sostituendo le variabili:

Test dll singolo:

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

Test di DLL multiple utilizzando progetti di test NUnit :

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

1. In Azioni post-compilazione , seleziona Pubblica rapporto sui risultati del test NUnit
2. Per la casella di testo XML del report di prova , immettere nunit-result.xml

Una volta che il progetto è stato creato, NUNit verrà eseguito ei risultati saranno visualizzabili sulla Dashboard (se si passa con il mouse sopra l'icona del bollettino meteorologico) o sulla pagina del progetto sotto Ultimo risultato del test .

È anche possibile eseguire il comando da Visual Studio o come parte del processo di compilazione locale.

Ecco due post del blog che ho usato come riferimento. Non ho trovato nessuno che corrispondesse esattamente alle mie esigenze:
1-Hour Guide to Continuous Integration Setup: Jenkins meets .Net (2011)
Guide to building .NET projects using Hudson (2008)

Se non vuoi codificare come hardcoded i tuoi progetti di unit test, è meglio scrivere uno script per prendere tutte le DLL del tuo progetto di unit test. Lo facciamo con Powershell e seguiamo una convenzione specifica per denominare i nostri progetti di unit test. Ecco il contenuto del file PowerShell che esegue i nostri unit test:

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

Lo script è abbastanza robusto da poter essere riutilizzato per tutti i nostri lavori di costruzione. Se non ti piace il percorso completo della console NUnit, puoi sempre inserire quella posizione nella variabile d'ambiente PATH.

Quindi mettiamo il file RunUnitTests.ps1 sul nostro server di compilazione e usiamo questo comando batch:

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

Per il lavoro agricolo Nunit 3 o superiore:

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

2. Passaggio di post per la pubblicazione di report Nunit, mostra solo il file dei risultati dei test nella directory dello spazio di lavoro di Jenkins, non nel progetto: TestR.xml

Dobbiamo creare i risultati dei test in formato nunit2 perché ora il plug-in Nunit di Jenkins non riconosce il formato dei risultati di Nunit3. Anche il formato della stringa delle opzioni è diverso: --result=TestR.xml;format=nunit2 NOT /xml=nunit-result.xml

Funziona bene, l'ho già impostato prima.

Configurare NUnit per l'output dei risultati in un file XML e configurare il plug-in Jenkins di NUnit per utilizzare questo file XML. I risultati saranno disponibili sulla dashboard.

Ora, dipende da te come invocare NUnit. Il modo in cui lo abbiamo fatto è stato: il lavoro Jenkins esegue il target NAnt esegue la suite di test NUnit.

È possibile configurare i lavori Jenkins in modo che vengano eseguiti su commit e / o pianificati in un determinato momento.

La soluzione di Ralph Willgoss funziona bene, ma ho cambiato 2 cose per renderla eccezionale:

a) Ho usato direttamente un progetto NUnit invece del file DLL. Ciò semplifica l'aggiunta di più assembly o la configurazione del test nella GUI di NUnit.

b) Ho aggiunto un'altra riga al batch per evitare che la build fallisca quando un test fallisce:

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

Il plug-in NUnit menzionato contrassegna automaticamente la build INSTABLE , che è esattamente quello che voglio, ogni volta che un test fallisce. Si vede con un punto giallo.

Penso che sia meglio fallire la build quando non passa, quindi non la distribuisci. Fai qualcosa del genere:

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%

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

Jenkins ha plugin che lo supporteranno. La configurazione esatta dipenderà molto dalla configurazione del progetto. Ci sono plugin specifici per nUnit, MSBuild, nAnt ecc. Inizia guardando la pagina dei plugin, ma non dovrebbe essere molto difficile capirlo.

Questa è la mia soluzione per eseguire OpenCover con 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

Ogni dll di test viene eseguita in un proprio processo perché abbiamo avuto problemi ad eseguire tutte le dll di test in un unico processo (problemi con caricamento assembly).

Per .Net Core è sufficiente aggiungere la fase di compilazione "Esegui shell" con il seguente script:

#!bash -x

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

Successivamente, aggiungi l'azione post-build "Pubblica rapporto sui risultati del test MSTest" per rendere visibili i risultati del test.

Il percorso predefinito dei rapporti di prova dovrebbe essere **/*.trxe pubblicherà tutti i .trxfile prodotti .