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

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 test unitaire. 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 être réutilisé pour tous nos travaux de construction. Si vous n'aimez pas le chemin complet vers la console NUnit, vous pouvez toujours mettre cet emplacement dans votre La 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"

Pour Nunit 3 ou plus Travaux agricoles:

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. Post step pour la publication du rapport Nunit, il 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 des résultats Nunit3. Aussi Options format de chaîne est différent: --result=TestR.xml;format=nunit2 PAS /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 Plugin NUnit Jenkins pour consommer ce fichier XML. Les résultats seront disponibles sur le tableau de bord.

Maintenant, comment vous invoquez NUnit est à vous. Comme nous l'avons fait, il était: Le travail 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 certain moment.

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 rend plus facile d'ajouter plus d'assemblys ou de configurer le test dans L'interface graphique NUnit.

B) j'ai ajouté une ligne supplémentaire au lot pour empêcher la construction d'échouer quand 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 UNSTABLE, ce qui est exactement ce que je veux, chaque fois qu'un test échouer. Il montre avec un point jaune.

Je pense qu'il vaut mieux échouer la construction quand elle ne passe pas pour 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 le supporteront. La configuration exacte va dépendre 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 terriblement difficile à comprendre.

C'est ma solution pour l'exécution de 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 dans un seul procress (probmels avec chargement d'assemblage).