Як ви запускаєте тести NUnit від Jenkins?


108

Я шукаю запускати автоматизовані тести NUnit для додатка C #, щовечора, і на кожній комісії до svn.

Це щось, що може зробити Дженкінс-КІ?
Чи є підручник в Інтернеті або як документувати, які документи подібні до налаштування, які я можу переглянути?


Ви ще щось шукаєте?
jglouie

1
Я шукаю навчальний посібник чи документацію з аналогічною установкою.
blueberryfields

1
У вас NUnit виконує тести так, як вам потрібно з командного рядка? Якщо ні, то це крок 1
jglouie

Відповіді:


120

Мені потрібно було робити саме те, що ти робиш, ось як я налаштував Дженкінса на це:

  1. Додайте плагін NUnit до Дженкінса
  2. У своєму проекті перейдіть до пункту Налаштування -> Збірка -> Додати крок збірки
  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-годинний посібник із налаштування безперервної інтеграції: Дженкінс відповідає. Net (2011)
Посібник зі створення .NET-проектів за допомогою Хадсона (2008)


Я не бачу, як цього достатньо. Чи нормально мати лише один (або кілька) тестових значень? У нас їх багато, і вони створюються та видаляються часто. Чи не повинно бути способу це зробити без необхідності жорсткого кодування тесту на дженкінсах?
Андре К. Андерсен

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

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

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

2
А-а-а. Моя логічна помилка полягала в тому, що плагін NUnit створив новий тип "Build-Task". Його чарівний вуду - це подія після побудови. (І просто використовується звичайний командний рядок для створення .xml)
granadaCoder

16

Якщо ви не хочете жорстко кодувати свої тестові проекти, вам краще написати сценарій, щоб захопити всі DLL-програми для вашого тесту. Ми робимо це з Powershell і дотримуємось конкретної конвенції щодо назви наших проектів тестування одиниць. Ось вміст файлу powerhell, який виконує наші тестові одиниці:

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"

добре працював, але у мене було два питання. Спочатку був вихідний каталог. Я повинен був змінити sourcedirectory на [string] $sourceDirectory = $(get-location)та для шляхів з пробілами, я повинен був змінити пропуск збірки на nUnit на$cFiles = $cFiles + '"' + $file + '"' + " "
Choco Smith

Якщо у нас є Тест, який ми виконуємо Тестовим списком. Чи можемо ми виконати цей тестовий список відтворення для Jenkins, використовуючи .dll?
Ішита Шах

15

Для фермерської роботи Nunit 3 або вище:

  1. Крок побудови (командний рядок 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, він показує лише файл результатів тестування в каталозі робочої області Дженкінса, а не у вашому проекті: TestR.xml

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


8

Це добре працює, я це встановлював раніше.

Налаштуйте NUnit для виведення результатів у файл XML та налаштуйте плагін NUnit Jenkins для споживання цього файлу XML. Результати будуть доступні на інформаційній панелі.

Тепер, як ви викликаєте NUnit, залежить від вас. Так, як ми це зробили: робота Дженкінса виконує цілі NAnt, виконуючи тестовий набір NUnit.

Ви можете налаштувати завдання Дженкінса для запуску та / або запланованого на певний час.


Це майже те, за що я пішов, але я не зміг заставити плагін NUnit працювати з конвеєра / робочого процесу. Я використовував плагін XUnit, натомість працював чудово.
demoncodemonkey

4

Рішення від Ральфа Вілгосса працює добре, але я змінив 2 речі, щоб зробити його чудовим:

a) Я використовував проект NUnit замість файлу DLL безпосередньо. Це полегшує додавання більшої кількості збірок або налаштування тесту в GUI NUnit.

b) Я додав ще один рядок до партії, щоб запобігти збій збірки, коли тест не вдався:

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

Згаданий плагін NUnit автоматично позначає збірку НЕСТАБОЛЬНО , що саме я хочу, коли тест не завершується. Він зображений жовтою крапкою.


3
Чому б ви не хотіли, щоб збірка вийшла з ладу, якщо тест модуля провалився? Якщо невдалий тест не повинен вказувати, що ви не хочете продовжувати розгортання?
Кірк Волл

1
Я також будую свої солянки з джинкінами, і я не хочу, щоб вони вийшли з ладу, якщо вони збираються, щоб я міг перевірити все інше. "нестабільний" -статус дає мені підказку, що не все працює так, як передбачалося. Нестабільний. Якщо збірка випуску нестабільна, я не буду її розгортати.
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 в моїй роботі Дженкінса. Дженкінс вважає останню команду ERRORLEVEL, тому вона не працювала для мене.
Акіра Ямамото

Чи запобігає це переваги кроку публікації? Я хочу, щоб плагін мав просту побудову позначки як "" за невдалої конфігурації тесту.
Томмі Холман

1

У Дженкінса є плагіни, які це підтримуватимуть. Точна конфігурація дуже залежатиме від налаштування вашого проекту. Існують конкретні плагіни для 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.