Comment exécutez-vous les tests NUnit de Jenkins?

Je cherche à exécuter des tests NUnit automatisés pour une application C #, de nuit et à chaque validation de svn.

Est-ce quelque chose que Jenkins-CI peut faire?
Existe-t-il un didacticiel en ligne ou un document pratique qui documente une configuration similaire que je peux examiner?

Je devais faire exactement ce que tu fais, voici comment je configure Jenkins pour faire ceci:

  1. Ajoutez le plug-in NUnit à Jenkins
  2. Dans votre projet, allez dans Configurer -> Construire -> Ajouter une étape de construction
  3. Dans la liste déroulante, descendez jusqu’à -> Exécuter Windows Batch Command
  4. Assurez-vous que cette étape est placée après votre étape MSBuild
  5. Ajoutez ce qui suit en remplaçant les variables:

Test dll unique:

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

Test dll multiple en utilisant des projets de test NUnit :

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

  1. Sous Actions post-construction , cochez Publier le rapport des résultats du test NUnit
  2. Pour la zone de texte Test Report XML , entrez nunit-result.xml

Une fois votre projet construit, NUNit s’exécutera et les résultats seront visibles sur le tableau de bord (si vous passez la souris sur l’icône du rapport météo) ou sur la page du projet sous Dernier résultat du test .

Vous pouvez également exécuter la commande depuis Visual Studio ou dans le cadre de votre processus de génération local.

Voici deux articles de blog que j’ai utilisés pour référence. Je n’ai pas trouvé qui correspondait exactement à mes besoins:
Guide d’une heure sur la configuration de l’continuous integration: Jenkins rencontre .Net (2011)
Guide pour la construction de projets .NET en utilisant Hudson (2008)

Si vous ne voulez pas coder en dur vos projets de test unitaire, il est préférable d’écrire un script pour saisir toutes les DLL de votre projet de test unitaire. Nous le faisons avec Powershell et suivons une convention spécifique pour nommer nos projets de tests unitaires. Voici le contenu du fichier powershell qui exécute nos tests unitaires:

 param( [ssortingng] $sourceDirectory = $env:WORKSPACE , $fileFilters = @("*.UnitTests.dll", "*_UnitTests.dll", "*UnitTests.dll") , [ssortingng]$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 

Le script est suffisamment robuste pour être réutilisé pour tous nos jobs de build. Si vous n’aimez pas le chemin d’access complet à la console NUnit, vous pouvez toujours placer cet emplacement dans votre variable d’environnement PATH.

Ensuite, nous mettons le fichier RunUnitTests.ps1 sur notre serveur de build et utilisons cette commande batch:

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

Pour Nunit 3 ou plus farmework:

  1. Etape de construction (ligne de commande 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. Après l’étape de publication des rapports Nunit, seuls les résultats du test sont affichés dans le répertoire de travail Jenkins, pas dans votre projet: TestR.xml

Nous devons faire des résultats de test au format nunit2 car le plugin Jenkins Nunit ne reconnaît plus le format de résultats Nunit3. Le format des chaînes d’options est également différent: --result=TestR.xml;format=nunit2 NOT /xml=nunit-result.xml

Cela fonctionne bien, je l’ai déjà mis en place.

Configurez NUnit pour afficher les résultats dans un fichier XML et configurez le plug-in NUnit Jenkins pour qu’il utilise ce fichier XML. Les résultats seront disponibles sur le tableau de bord.

Maintenant, comment vous invoquez NUnit? La façon dont nous l’avons fait était la suivante: le travail de Jenkins exécute la cible NAnt exécute la suite de tests NUnit.

Vous pouvez configurer les travaux Jenkins pour qu’ils s’exécutent sur commit et / ou planifiés à un moment donné.

La solution de Ralph Willgoss fonctionne bien, mais j’ai changé 2 choses pour le rendre génial:

a) J’ai utilisé un projet NUnit au lieu du fichier DLL directement. Cela facilite l’ajout d’assemblages ou la configuration du test dans l’interface graphique de NUnit.

b) J’ai ajouté une ligne supplémentaire au lot pour éviter que la génération échoue lorsqu’un test échoue:

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

Le plug- in NUnit mentionné marque automatiquement la construction UNSTABLE , ce qui est exactement ce que je veux, chaque fois qu’un test échoue. Il montre avec un point jaune.

Je pense qu’il est préférable d’échouer la construction quand elle ne passe pas, donc vous ne la déployez pas. Faites quelque chose comme ça:

 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% 

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

Jenkins a des plugins qui supporteront cela. La configuration exacte dépendra beaucoup de la configuration de votre projet. Il existe des plugins spécifiques pour nUnit, MSBuild, nAnt etc. Commencez par regarder la page des plugins, mais cela ne devrait pas être très difficile à comprendre.

Voici ma solution pour exécuter OpenCover avec vstest dans Jenkins:

 param( [ssortingng] $sourceDirectory = $env:WORKSPACE , $includedFiles = @("*Test.dll") , $excludedFiles = @("*.IGNORE.dll") , [ssortingng]$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 

Chaque dll de test est exécutée dans un processus propre, car nous avons eu des problèmes pour exécuter tous les dll de test dans un processus unique (avec le chargement de l’assembly).