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

Je cherche à exécuter des tests NUnit automatisés pour une application C #, tous les soirs et à chaque commit sur 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?

J'avais besoin de faire exactement ce que vous faites, voici comment j'ai configuré Jenkins pour le faire:

1. Ajouter le plug-in NUnit à Jenkins
2. Dans votre projet, allez dans Configurer -> Construire -> Ajouter une étape de construction
3. Dans la liste déroulante, faites défiler jusqu'à -> Exécuter la commande Windows Batch
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 de plusieurs dll à l'aide de projets de test NUnit :

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

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

Une fois que votre projet a été construit, NUNit s'exécutera et les résultats seront visibles soit sur le tableau de bord (si vous survolez l'icône du rapport météo), soit 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 génération local.

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

Si vous ne voulez pas coder en dur vos projets de test unitaire, il vaut mieux écrire un script pour récupérer 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(
[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 le réutilisions pour tous nos travaux de construction. Si vous n'aimez pas le chemin complet de 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 supérieur 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. Étape de publication pour la publication de rapports Nunit, elle affiche uniquement le fichier de résultats de test dans le répertoire de l'espace de travail Jenkins, pas dans votre projet: TestR.xml

Nous devons faire des résultats de test au format nunit2 car maintenant le plugin 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 NON /xml=nunit-result.xml

Cela fonctionne bien, je l'ai déjà configuré.

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

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

Vous pouvez configurer les tâches Jenkins pour qu'elles s'exécutent lors de la validation et / ou planifiées à une certaine heure.

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'autres assemblys ou la configuration du test dans l'interface graphique NUnit.

b) J'ai ajouté une ligne de plus au lot pour éviter que la construction échoue lorsqu'un test échoue:

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

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

Je pense qu'il vaut mieux échouer la construction quand elle ne passe pas afin de ne pas la déployer. Faites quelque chose comme ceci:

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 prendront en charge cela. La configuration exacte dépendra un peu 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(
[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 (problèmes avec le chargement de l'assembly).

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 l'action post-build «Publier le rapport de résultat du test MSTest» pour rendre les résultats du test visibles.

Le chemin par défaut des rapports de test doit être **/*.trxet publiera tous les .trxfichiers produits .