¿Cómo haces las pruebas NUnit de Jenkins?

Si no desea codificar sus proyectos de prueba unitaria, es mejor escribir un script para capturar todas las DLL de su proyecto de prueba Unitaria. Lo hacemos con Powershell y seguimos una convención específica para nombrar nuestros proyectos de Prueba Unitaria. Aquí está el contenido del archivo de powershell que ejecuta nuestras pruebas unitarias:

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

El script es lo suficientemente robusto como para que lo estemos reutilizando para todos nuestros trabajos de construcción. Si no te gusta el camino completo a la consola NUnit, siempre puedes poner esa ubicación en tu Variable de entorno PATH.

Luego ponemos el archivo RunUnitTests. ps1 en nuestro servidor de compilación y usamos este comando por lotes:

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

Para el trabajo agrícola Nunit 3 o superior:

1. Paso de construcción (línea de comandos de 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. Paso de publicación para la publicación del informe Nunit, muestra solo el archivo de resultados de la prueba en el directorio del espacio de trabajo de Jenkins, no en su proyecto: TestR.xml

Necesitamos hacer los resultados de la prueba en formato nunit2 porque ahora Jenkins Nunit plugin no reconoce Nunit3 formato de resultados. También opciones formato de cadena es diferente: --result=TestR.xml;format=nunit2 NI /xml=nunit-result.xml

Esto funciona muy bien, ya lo he configurado antes.

Configure NUnit para enviar los resultados a un archivo XML y configure el complemento NUnit Jenkins para consumir este archivo XML. Los resultados estarán disponibles en el panel de control.

Ahora, cómo invoques a NUnit depende de ti. La forma en que lo hicimos fue: Jenkins job ejecuta Nant target ejecuta NUnit test suite.

Puede configurar los trabajos de Jenkins para que se ejecuten en la confirmación y/o programados en un momento determinado.

La solución de Ralph Willgoss está funcionando bien, pero cambié 2 cosas para hacerlo genial:

A) Usé un proyecto NUnit en lugar del archivo DLL directamente. Esto hace que sea más fácil agregar más ensamblados o configurar la prueba en la GUI de NUnit.

B) Agregué una línea más al lote para evitar que la compilación falle cuando falla una prueba:

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

El plugin NUnit mencionado marca la compilación INESTABLE automáticamente, que es exactamente lo que quiero, cada vez que una prueba fallar. Se muestra con un punto amarillo.

Creo que es mejor fallar la compilación cuando no pasa para no implementarla. Haga algo como esto:

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%

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

Jenkins tiene plugins que soportarán eso. La configuración exacta va a depender bastante de la configuración de su proyecto. Hay plugins específicos para NUnit, MSBuild, nAnt, etc. Comience por mirar la página de plugins, pero no debería ser terriblemente difícil de averiguar.

Esta es mi solución para ejecutar OpenCover con vstest en 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

Cada dll de prueba se ejecuta en un proceso propio porque tuvimos problemas para ejecutar todas las dll de prueba en una sola procress (probmels con carga de ensamblado).