Как вы запускаете тесты NUnit из Jenkins?


108

Я хочу запускать автоматические тесты NUnit для приложения C # каждую ночь и при каждой фиксации в svn.

Может ли это Jenkins-CI?
Есть ли онлайн-учебник или практический документ, в котором описана аналогичная установка, которую я могу просмотреть?


Вы еще что-нибудь ищете?
jglouie

1
Я ищу учебное пособие или практический документ с аналогичной настройкой.
blueberryfields

1
У вас есть NUnit, запускающий тесты, как вы хотите, из командной строки? Если нет, то это шаг 1
jglouie

Ответы:


120

Мне нужно было делать именно то, что вы делаете, вот как я настраиваю Дженкинса для этого:

  1. Добавьте плагин NUnit в Jenkins
  2. В вашем проекте перейдите в Configure -> Build -> Add a build step.
  3. В раскрывающемся списке прокрутите вниз до -> Выполнить пакетную команду Windows.
  4. Убедитесь, что этот шаг размещен после шага MSBuild
  5. Добавьте следующее, заменив переменные:

Тест одиночной dll:

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

Тестирование нескольких dll с использованием тестовых проектов NUnit :

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

  1. В разделе Действия после сборки установите флажок Опубликовать отчет о результатах тестирования NUnit.
  2. Для текстового поля «Отчет о тестировании XML» введите nunit-result.xml.

После создания проекта NUNit будет запущен, и результаты будут доступны для просмотра либо на панели инструментов (если вы наведете курсор на значок отчета о погоде), либо на странице проекта в разделе « Последний результат теста» .

Вы также можете запустить команду из Visual Studio или как часть локального процесса сборки.

Вот два сообщения в блоге, которые я использовал для справки. Я не нашел ни одного, которое точно соответствовало бы моим требованиям:
1-часовое руководство по настройке непрерывной интеграции: Jenkins встречает .Net (2011 г.)
Руководство по созданию проектов .NET с использованием Hudson (2008 г.)


Я действительно не понимаю, насколько этого достаточно. Нормально ли иметь только одну (или несколько) тестовых dll? У нас их много, и они часто создаются и удаляются. Разве не должен быть способ сделать это без необходимости жестко кодировать тест для Дженкинса?
Андре К. Андерсен

Укажите на этапе сборки использование файла .bat или .cmd в системе управления версиями, что запускает вашу команду NUnit. Теперь вы можете изменять тесты, которые будут запускаться сколь угодно часто, не меняя Jenkins. Вам также следует взглянуть на тестовые проекты NUnit, так как это тоже может вам помочь. Ключ сообщает Jenkins, какой XML-файл использовать для отчета о тестировании.
Ральф Уиллгосс

4
просто используйте файл * .nunit в качестве параметра вместо файла DLL, например "C:\Program Files (x86)\NUnit 2.6.3\bin\nunit-console-x86.exe" UnitTests/UnitTests.nunit. У меня отлично сработало.
JCH2k 08

3
Вы можете использовать файл * .sln вместо DLL, см. Документацию
Мартин

2
Аааа. Моя логическая ошибка заключалась в том, что плагин NUnit создал новый тип «Build-Task». Его волшебное вуду - это событие после сборки. (И для генерации .xml просто используется обычная командная строка)
granadaCoder

16

Если вы не хотите жестко кодировать свои проекты модульного тестирования, вам лучше написать сценарий, чтобы получить все библиотеки dll вашего проекта модульного теста. Мы делаем это с помощью Powershell и следуем определенному соглашению для именования наших проектов модульного тестирования. Вот содержимое файла PowerShell, в котором выполняются наши модульные тесты:

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

Скрипт достаточно надежен, поэтому мы повторно используем его для всех наших задач сборки. Если вам не нравится полный путь к консоли NUnit, вы всегда можете указать это местоположение в переменной среды PATH.

Затем мы помещаем файл RunUnitTests.ps1 на наш сервер сборки и используем эту пакетную команду:

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

работал хорошо, но у меня было две проблемы. сначала был исходный каталог. Я должен был изменить Исходный_каталог к [string] $sourceDirectory = $(get-location)и для путей с пробелами я должен был изменить узел переходит к NUnit в$cFiles = $cFiles + '"' + $file + '"' + " "
Choco Смит

Если у нас есть Test, который мы выполняем с помощью Test Playlist. Можем ли мы выполнить этот тестовый плейлист для Jenkins, используя .dll?
Ishita Shah

15

Для Nunit 3 и выше:

  1. Building Step (командная строка 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. Шаг публикации для публикации отчета Nunit, он показывает только файл результатов теста в каталоге рабочей области Jenkins, а не в вашем проекте: TestR.xml

Нам нужно сделать результаты тестов в формате nunit2, потому что теперь плагин Jenkins Nunit не распознает формат результатов Nunit3. Также формат строки параметров отличается: --result=TestR.xml;format=nunit2 НЕ /xml=nunit-result.xml


8

Это прекрасно работает, я уже настраивал это раньше.

Настройте NUnit для вывода результатов в файл XML и настройте подключаемый модуль NUnit Jenkins для использования этого файла XML. Результаты будут доступны на панели управления.

Теперь, как вы вызываете NUnit, зависит от вас. Мы сделали это следующим образом: задание Jenkins выполняет NAnt target выполняет набор тестов NUnit.

Вы можете настроить задания Jenkins для запуска при фиксации и / или по расписанию в определенное время.


Это почти то, что я сделал, но мне не удалось заставить плагин NUnit работать из конвейера / рабочего процесса. Вместо этого я использовал плагин XUnit, который работал нормально.
demoncodemonkey

4

Решение от Ральфа Уиллгосса работает хорошо, но я изменил 2 вещи, чтобы сделать его отличным:

а) Я использовал проект NUnit вместо файла DLL напрямую. Это упрощает добавление дополнительных сборок или настройку теста в графическом интерфейсе NUnit.

б) Я добавил в пакет еще одну строчку, чтобы не допустить сбоя сборки в случае сбоя теста:

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

Упомянутый плагин NUnit автоматически помечает сборку как НЕСТАБИЛЬНУЮ , что я и хочу, когда тест не проходит. Он отображается желтой точкой.


3
Почему бы вам не захотеть, чтобы сборка завершилась ошибкой, если модульный тест не прошел? Разве неудавшийся тест не должен указывать на то, что вы не хотите продолжать развертывание?
Кирк Уолл,

1
Я также создаю свои ночные сборники с помощью jenkins, и я не хочу, чтобы они терпели неудачу, если они компилируются, поэтому я могу протестировать все остальное. "нестабильный" статус подсказывает мне, что не все работает, как предполагалось. Нестабильный. Если сборка релиза нестабильна, я не буду ее развертывать.
JCH2k

2

Я думаю, что лучше отказать сборке, если она не прошла, чтобы не развертывать ее. Сделайте что-нибудь вроде этого:

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%

Ссылка: http://www.greengingerwine.com/index.php/2013/01/tip-check-errorlevel-in-your-post-build-steps-when-using-nunit/


делает ли это что-то большее, чем одна только первая строка? я так не думаю. сборка в любом случае завершается ошибкой, если nunit-console.exe возвращает! = 0, что происходит в случае неудачи теста.
JCH2k

Я забыл сказать, что у меня были некоторые команды после вызова nunit-console.exe в моей работе Jenkins. Дженкинс считает только последнюю команду ERRORLEVEL, поэтому у меня она не сработала.
Акира Ямамото

Мешает ли это преимуществам этапа публикации? Я бы хотел, чтобы у плагина была простая пометка "" при неудачной тестовой конфигурации.
Томми Холман

1

У Jenkins есть плагины, которые это поддерживают. Точная конфигурация будет сильно зависеть от настроек вашего проекта. Существуют специальные плагины для nUnit, MSBuild, nAnt и т. Д. Начните с просмотра страницы плагинов, но понять это не должно быть очень сложно.


1

Это мое решение для запуска OpenCover с vstest в 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

Каждая тестовая dll выполняется в отдельном процессе, потому что у нас возникли проблемы с выполнением всех тестовых dll в одном процессе (проблемы с загрузкой сборки).


0

Для .Net Core достаточно добавить шаг сборки «выполнить оболочку» со следующим скриптом:

#!bash -x

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

После этого добавьте действие после сборки «Опубликовать отчет о результатах теста MSTest», чтобы результаты теста были видны.

Путь к отчетам по умолчанию должен быть **/*.trxи будет публиковать все созданные .trxфайлы.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.