web-dev-qa-db-fra.com

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

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

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

c#continuous-integrationhudsonjenkins
104
blueberryfields

Je devais faire exactement ce que vous faites, voici comment j'ai configuré Jenkins pour le faire:

  1. Ajouter le plugin NUnit à Jenkins
  2. Dans votre projet, allez à Configurez -> Construisez -> Ajouter une étape de construction
  3. Dans le menu déroulant, faites défiler vers le bas pour -> Exécuter la commande batch de Windows
  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 de DLL unique:

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

Test de plusieurs DLL avec projets de test NUnit :

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

  1. Sous Actions post-build , cochez Publiez le rapport du résultat du test de publication NUnit .
  2. Pour la zone de texte XML du rapport de test , entrez nunit-result.xml

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

Vous pouvez également exécuter la commande à partir de Visual Studio ou dans le cadre de votre processus de construction local.

Voici deux articles de blog que j'ai utilisés pour référence. Je n'en ai trouvé aucun qui corresponde exactement à mes exigences:
Guide 1 heure pour la configuration de l'intégration continue: Jenkins rencontre .Net (2011)
Guide pour la construction de projets .NET avec Hudson (2008)

114
Ralph Willgoss

Si vous ne voulez pas coder en dur vos projets de tests unitaires, il est préférable d'écrire un script pour récupérer toutes les dll de vos projets de tests unitaires. 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(
[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

Le script est suffisamment robuste pour que nous puissions le réutiliser pour tous nos travaux de construction. Si vous n'aimez pas le chemin d'accès complet à la console NUnit, vous pouvez toujours mettre cet emplacement dans votre variable d'environnement PATH.

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

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

Pour Nunit 3 ou plus farmework:

  1. Étape 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. Publiez l’étape pour la publication du rapport Nunit, elle affiche uniquement les résultats du test dans le répertoire de l’espace de travail Jenkins, pas dans votre projet: TestR.xml

Nous devons créer des résultats de test au format nunit2 car maintenant, le plug-in Jenkins Nunit ne reconnaît pas le format de résultats Nunit3. Le format de la chaîne d'options est également différent: --result=TestR.xml;format=nunit2 NE PAS /xml=nunit-result.xml

13
Winston33

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

Configurez NUnit pour exporter les résultats dans un fichier XML et configurez le NUnit Jenkins Plugin pour utiliser ce fichier XML. Les résultats seront disponibles sur le tableau de bord.

Maintenant, comment vous appelez NUnit est à vous. Nous avons procédé comme suit: le travail Jenkins exécute NAnt La cible exécute la suite de tests NUnit.

Vous pouvez configurer les travaux Jenkins pour qu'ils s'exécutent sur commit et/ou soient programmés à une heure donnée.

8
jglouie

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

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

b) J'ai ajouté une ligne supplémentaire au lot pour empêcher la génération d'échouer en cas d'échec du test:

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

Le plugin NUnit mentionné marque la construction INSTABLE , ce qui est exactement ce que je veux, chaque fois qu'un test échoue. Il montre avec un point jaune.

4
JCH2k

Je pense qu'il vaut mieux échouer la construction quand elle ne passe pas pour ne pas la déployer. 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/

2
Akira Yamamoto

Voici ma solution pour exécuter OpenCover avec vstest dans 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

Chaque dll de test est exécutée dans un processus propre car nous avons eu des problèmes pour exécuter toutes les dll de test en un seul processus (probmels avec le chargement de l’Assembly).

1
MeJ

Jenkins a des plugins qui vont supporter ça. 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.

1
Matt

Pour .Net Core, il suffit d'ajouter l'étape de construction "execute Shell" avec le script suivant:

#!bash -x

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

Après cela, ajoutez une action post-build "Publier le résultat du test MSTest" pour rendre les résultats du test visibles.

Le chemin des rapports de test par défaut doit être **/*.trx _ et publiera tous les produits .trx des dossiers.

0
stop-cran