Como você executa os testes NUnit do Jenkins?

Estou tentando executar testes NUnit automatizados para um aplicativo C #, todas as noites e em cada commit para svn.

Isso é algo que o Jenkins-CI pode fazer?
Existe um tutorial online ou documento de instruções que documenta uma configuração semelhante que eu possa consultar?

Eu precisava fazer exatamente o que você faz, eis como configurei o Jenkins para fazer isso:

1. Adicione o plug-in NUnit ao Jenkins
2. Em seu projeto, vá para Configurar -> Construir -> Adicionar uma etapa de construção
3. No menu suspenso, role para baixo até -> Executar comando em lote do Windows
4. Certifique-se de que esta etapa seja colocada após sua etapa do MSBuild
5. Adicione o seguinte, substituindo as variáveis:

Teste de dll único:

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

Teste de dll múltiplo usando projetos de teste NUnit :

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

1. Em Ações de pós-construção , marque Publicar relatório de resultado de teste NUnit
2. Para os XMLs do relatório de teste da caixa de texto , insira nunit-result.xml

Assim que o projeto tiver sido construído, o NUNit será executado e os resultados poderão ser visualizados no Painel (se você passar o mouse sobre o ícone do relatório meteorológico) ou na página do projeto em Resultado do Último Teste .

Você também pode executar o comando de dentro do Visual Studio ou como parte do processo de compilação local.

Aqui estão duas postagens de blog que usei como referência. Não encontrei nenhum que
atendesse exatamente aos meus requisitos: Guia de 1 hora para configuração de integração contínua: Jenkins atende .Net (2011)
Guia para construção de projetos .NET usando Hudson (2008)

Se você não quiser codificar seus projetos de teste de unidade, é melhor escrever um script para obter todas as dlls de seus projetos de teste de unidade. Fazemos isso com o Powershell e seguimos uma convenção específica para nomear nossos Projetos de Teste de Unidade. Aqui está o conteúdo do arquivo powershell que executa nossos testes de unidade:

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

O script é robusto o suficiente para ser reutilizado em todos os nossos trabalhos de construção. Se você não gosta do caminho completo para o console NUnit, você sempre pode colocar esse local em sua variável de ambiente PATH.

Em seguida, colocamos o arquivo RunUnitTests.ps1 em nosso servidor de compilação e usamos este comando em lote:

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

Para trabalho agrícola Nunit 3 ou superior:

1. Etapa de construção (linha de comando do 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. Pós-etapa para publicação de relatório Nunit, mostra apenas o arquivo de resultados de teste no diretório do espaço de trabalho do Jenkins, não em seu projeto: TestR.xml

Precisamos fazer os resultados do teste no formato nunit2 porque agora o plugin Jenkins Nunit não reconhece o formato de resultados Nunit3. Além disso, o formato da string de opções é diferente: --result=TestR.xml;format=nunit2 NÃO /xml=nunit-result.xml

Isso funciona bem, eu configurei isso antes.

Configure o NUnit para produzir os resultados em um arquivo XML e configure o plug - in NUnit Jenkins para consumir esse arquivo XML. Os resultados estarão disponíveis no painel.

Agora, como você invoca o NUnit é com você. A maneira como fizemos foi: Jenkins job executa NAnt target executa NUnit test suite.

Você pode configurar os trabalhos do Jenkins para serem executados na confirmação e / ou agendados em um determinado momento.

A solução de Ralph Willgoss está funcionando bem, mas eu mudei 2 coisas para torná-la ótima:

a) Usei um projeto NUnit em vez do arquivo DLL diretamente. Isso torna mais fácil adicionar mais assemblies ou configurar o teste na GUI do NUnit.

b) Eu adicionei mais uma linha ao lote para evitar que a compilação falhe quando um teste falhar:

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

O plug-in NUnit mencionado marca a build como UNSTABLE automaticamente, que é exatamente o que eu quero, sempre que um teste falha. Ele aparece com um ponto amarelo.

Eu acho que é melhor falhar a compilação quando ela não passa, para que você não a implante. Faça algo assim:

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%

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

Jenkins tem plug-ins que suportam isso. A configuração exata vai depender um pouco da configuração do seu projeto. Existem plug-ins específicos para nUnit, MSBuild, nAnt etc. Comece observando a página de plug-ins, mas não deve ser terrivelmente difícil de descobrir.

Esta é a minha solução para a execução de OpenCover com vstest em 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 teste é executado em um próprio processo porque tivemos problemas para executar todas as dlls de teste em um único processo (problemas com o carregamento do assembly).

Para .Net Core, é suficiente adicionar a etapa de compilação "execute shell" com o seguinte script:

#!bash -x

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

Depois disso, adicione a ação pós-compilação "Publicar relatório de resultado do teste MSTest" para tornar os resultados do teste visíveis.

O caminho padrão dos relatórios de teste deve ser **/*.trxe publicará todos os .trxarquivos produzidos .