Come si eseguono i test NUnit da Jenkins?


108

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?


c'è qualcos'altro che stai cercando?
jglouie

1
Sto cercando un tutorial o un documento di istruzioni con una configurazione simile.
blueberryfields

1
Hai NUnit che esegue i test come desideri dalla riga di comando? In caso contrario, questo è il passaggio 1
jglouie

Risposte:


120

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)


Non vedo davvero come sia sufficiente. È normale avere solo una (o poche) DLL di prova? Ne abbiamo un sacco e vengono creati e rimossi spesso. Non dovrebbe esserci un modo per farlo senza dover codificare il test in jenkins?
André C. Andersen

Indica il passaggio di compilazione a utilizzare un file .bat o .cmd sotto il controllo del codice sorgente, che avvia il comando NUnit. Ora puoi modificare i test che verranno eseguiti tutte le volte che vuoi senza cambiare Jenkins. Dovresti anche esaminare i progetti di test di NUnit, poiché anche questo potrebbe aiutarti. La chiave è dire a Jenkins quale file xml utilizzare per il rapporto di prova.
Ralph Willgoss

4
usa semplicemente il tuo file * .nunit come parametro invece del file DLL, ad es "C:\Program Files (x86)\NUnit 2.6.3\bin\nunit-console-x86.exe" UnitTests/UnitTests.nunit. Ha funzionato perfettamente per me.
JCH2k

3
È possibile utilizzare il file * .sln invece della DLL, vedere la documentazione
Martin

2
Ahhh. Il mio errore logico era che il plugin NUnit ha creato un nuovo tipo "Build-Task". Il suo magico vudù è l'evento Post-Build. (E si usa solo la normale riga di comando per generare il .xml)
granadaCoder

16

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"

ha funzionato bene ma ho avuto due problemi. prima era la directory di origine. Ho dovuto cambiare la directory di origine in [string] $sourceDirectory = $(get-location)e per i percorsi con spazi ho dovuto cambiare il pass di assemblaggio in nUnit a$cFiles = $cFiles + '"' + $file + '"' + " "
Choco Smith

Se abbiamo Test, che stiamo eseguendo da Test Playlist. Possiamo eseguire questa playlist di prova per Jenkins, usando .dll?
Ishita Shah

15

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


8

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.


Questo è quasi quello che cercavo, ma non sono riuscito a far funzionare il plug-in NUnit da una pipeline / flusso di lavoro. Ho usato invece il plugin XUnit che ha funzionato bene.
demoncodemonkey

4

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.


3
Perché non vuoi che la build fallisca se lo unit test fallisce? Il test fallito non dovrebbe indicare che non si desidera procedere con una distribuzione?
Kirk Woll

1
Creo anche i miei nightlies con jenkins e non voglio che falliscano se si compilano in modo da poter testare tutto il resto. lo stato "instabile" mi dà un suggerimento che non tutto funziona come previsto. Instabile. Se una build di rilascio è instabile, non la distribuirò.
JCH2k

2

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/


fa qualcosa di più della prima riga da sola? non credo proprio. la compilazione fallisce comunque se nunit-console.exe ritorna! = 0 cosa che fa se un test fallisce.
JCH2k

Ho dimenticato di dire che avevo alcuni comandi dopo aver chiamato nunit-console.exe nel mio lavoro Jenkins. Jenkins considera solo l'ultimo comando ERRORLEVEL quindi non ha funzionato per me.
Akira Yamamoto

Ciò impedisce i vantaggi della fase di pubblicazione? Vorrei che il plugin avesse un semplice contrassegno creato come "" nella configurazione di prova fallita.
Tommy Holman

1

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.


1

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).


0

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 .

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.