Come gestisci i test NUnit da Jenkins?

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

È qualcosa che Jenkins-CI può fare?
Esiste un tutorial online o un how-to document che documenta un setup simile che posso guardare?

Dovevo fare esattamente quello che fai, ecco come ho impostato Jenkins per farlo:

  1. Aggiungi il plugin NUnit a Jenkins
  2. Nel tuo progetto vai su Configura -> Crea -> Aggiungi un passo di costruzione
  3. Nel menu a discesa scorri fino a -> Esegui comando batch di Windows
  4. Assicurarsi che questo passaggio sia inserito dopo il passo MSBuild
  5. Aggiungi il seguente, sostituendo le variabili:

Test della singola dll:

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

Test di dll multipli utilizzando i progetti di test NUnit :

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

  1. In Azioni post-compilazione , selezionare Pubblica rapporto risultato test NUnit
  2. Per la textbox Test report XMLs , inserisci nunit-result.xml

Una volta che il progetto è stato creato, NUNit verrà ora eseguito e i risultati saranno visibili sul Dashboard (se si passa con il mouse sopra l’icona del bollettino meteorologico) o nella pagina del progetto in Risultato ultimo test .

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

Ecco due post sul blog che ho usato come riferimento. Non ho trovato nessuno che corrispondesse esattamente alle mie esigenze:
Guida di 1 ora alla configurazione di integrazione continua: Jenkins meets .Net (2011)
Guida alla creazione di progetti .NET usando Hudson (2008)

Se non si desidera eseguire l’hardcode dei progetti di test delle unità, è meglio scrivere uno script per acquisire tutte le dll del progetto Unit Test. Lo facciamo con Powershell e seguiamo una convenzione specifica per nominare i nostri progetti di test unitario. Ecco il contenuto del file PowerShell che esegue i nostri test unitari:

 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 solido da essere riutilizzato per tutti i nostri lavori di compilazione. Se non ti piace il percorso completo della console NUnit, puoi sempre inserire tale posizione nella variabile d’ambiente PATH.

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

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

Per Nunit 3 o sopra i lavori agricoli:

  1. Building Step (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. Post passo per la pubblicazione di report Nunit, mostra solo il file dei risultati del test nella directory dello spazio di lavoro di Jenkins, non nel tuo progetto: TestR.xml

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

Funziona bene, l’ho già impostato in precedenza.

Configura NUnit per inviare i risultati a un file XML e configurare il plugin NUnit Jenkins per consumare questo file XML. I risultati saranno disponibili sulla dashboard.

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

È ansible configurare i processi Jenkins per l’esecuzione su commit e / o pianificati in un determinato momento.

La soluzione di Ralph Willgoss sta funzionando bene, ma ho cambiato 2 cose per renderlo fantastico:

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

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

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

Il Plugin NUnit menzionato segnala automaticamente la compilazione INSTABILE , che è esattamente quello che voglio, ogni volta che un test fallisce. Mostra con un punto giallo.

Penso che sia meglio fallire la compilazione quando non passa così non lo si distribuisce. 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 dei plugin che lo supportano. La configurazione esatta dipenderà un po ‘dalla configurazione del tuo progetto. Esistono plugin specifici per nUnit, MSBuild, nAnt ecc. Inizia guardando la pagina dei plugin, ma non dovrebbe essere terribilmente difficile da capire.

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 nell’esecuzione di tutte le DLL di test in un singolo procress (probmel con caricamento di assembly).