Jenkins'ten NUnit testlerini nasıl çalıştırırsınız?


108

Bir C # uygulaması için her gece ve svn'ye yapılan her işlemde otomatikleştirilmiş NUnit testleri çalıştırmak istiyorum.

Bu Jenkins-CI'nin yapabileceği bir şey mi?
Bakabileceğim benzer bir kurulumu belgeleyen çevrimiçi bir eğitim veya nasıl yapılır dokümanı var mı?


aradığınız başka bir şey var mı?
jglouie

1
Benzer bir kurulumla bir eğitim veya nasıl yapılır belgesi arıyorum.
blueberryfields

1
Komut satırından istediğiniz gibi testleri çalıştıran NUnit'e sahip misiniz? Değilse, bu 1. adım
jglouie

Yanıtlar:


120

Yaptığınız şeyi tam olarak yapmam gerekiyordu, işte Jenkins'i bunu yapacak şekilde ayarladım:

  1. NUnit Eklentisini Jenkins'e Ekleyin
  2. Projenizde Yapılandır -> Oluştur -> Bir derleme adımı ekle'ye gidin
  3. Açılır menüde -> Windows Toplu İş Komutunu Çalıştır seçeneğine gidin
  4. Bu adımın MSBuild adımınızdan sonra yerleştirildiğinden emin olun
  5. Değişkenleri değiştirerek aşağıdakileri ekleyin:

Tek dll testi:

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

NUnit test projelerini kullanarak çoklu dll testi :

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

  1. Derleme Sonrası Eylemler altında , NUnit test sonucu raporunu yayınla seçeneğini işaretleyin
  2. Metin kutusu Test raporu XML'leri için nunit-result.xml girin

Projenizi oluşturduktan sonra, NUNit şimdi çalışacak ve sonuçlar Gösterge Panosunda (Hava durumu raporu simgesinin üzerine gelirseniz) veya Son Test Sonucu altındaki proje sayfasında görüntülenebilir olacaktır .

Komutu Visual Studio içinden veya yerel derleme işleminizin bir parçası olarak da çalıştırabilirsiniz.

İşte referans için kullandığım iki blog yazısı. Gereksinimlerime tam olarak uyan herhangi bir şey bulamadım:
Sürekli Entegrasyon Kurulumu için 1 Saatlik Kılavuz: Jenkins, .Net'i karşılar (2011)
Hudson (2008) kullanarak .NET projeleri oluşturma kılavuzu


Bunun nasıl yeterli olduğunu gerçekten anlamıyorum. Yalnızca bir (veya birkaç) test dll'sine sahip olmak normal mi? Onlardan bir sürü var ve sık sık yaratılıp kaldırılıyorlar. Bunu jenkins'e kodlamak zorunda kalmadan yapmanın bir yolu olması gerekmez mi?
André C. Andersen

Derleme adımını, NUnit komutunuzu başlatan kaynak denetimi altındaki bir .bat veya .cmd dosyası kullanma adımına yönlendirin. Artık, Jenkins'i değiştirmeden istediğiniz sıklıkta çalıştırılacak testleri değiştirebilirsiniz. Ayrıca size yardımcı olabileceği için NUnit Test Projelerine de bakmalısınız. Anahtar, Jenkins'e test raporu için hangi xml dosyasının kullanılacağını söylemektir.
Ralph Willgoss

4
DLL dosyası yerine parametre olarak * .nunit dosyanızı kullanın, örn "C:\Program Files (x86)\NUnit 2.6.3\bin\nunit-console-x86.exe" UnitTests/UnitTests.nunit. Benim için mükemmel çalıştı.
JCH2k

3
DLL yerine * .sln dosyasını kullanabilirsiniz, Belgelere
Martin

2
Ahhh. Mantıksal yanılgım, NUnit eklentisinin yeni bir "Build-Task" türü yaratmasıydı. Büyülü vudu, Post-Build olayıdır. (Ve biri
.xml'yi

16

Ünite testi projelerinizi kodlamak istemiyorsanız, tüm Unit Test proje dll'lerinizi almak için bir komut dosyası yazmanız daha iyi olur. Bunu Powershell ile yapıyoruz ve Birim Test Projelerimizi adlandırmak için belirli bir kuralı takip ediyoruz. Birim testlerimizi çalıştıran powershell dosyasının içeriği:

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

Komut dosyası, tüm derleme işlerimiz için yeniden kullanacağımız kadar sağlam. NUnit konsolunun tam yolunu beğenmezseniz, bu konumu her zaman PATH ortam değişkeninize koyabilirsiniz.

Daha sonra RunUnitTests.ps1 dosyasını derleme sunucumuza koyarız ve şu toplu komutu kullanırız:

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

iyi çalıştı ama iki sorunum vardı. ilk önce kaynak dizindi. Ben değiştirmek zorunda kaynak_dizini için [string] $sourceDirectory = $(get-location)ben montaj için NUNIT geçmek değiştirmek zorunda kaldı ve boşluk içeren yolları için$cFiles = $cFiles + '"' + $file + '"' + " "
Choco Smith

Test Oynatma Listesi ile yürüttüğümüz Testimiz varsa. Bu test çalma listesini .dll kullanarak Jenkins için çalıştırabilir miyiz?
Ishita Shah

15

Nunit 3 veya üzeri çiftlik işleri için:

  1. Bina Adımı (Windows komut satırı) "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 raporunun yayınlanması için adım adım, projenizde değil, yalnızca Jenkins çalışma alanı dizininde test sonuçları dosyasını gösterir: TestR.xml

Test sonuçlarını nunit2 formatında yapmamız gerekiyor çünkü artık Jenkins Nunit eklentisi Nunit3 sonuç formatını tanımıyor. Ayrıca seçenekler dizesi biçimi farklıdır: --result=TestR.xml;format=nunit2 NOT /xml=nunit-result.xml


8

Bu güzel çalışıyor, bunu daha önce ayarladım.

NUnit'i sonuçları bir XML dosyasına çıkacak şekilde yapılandırın ve NUnit Jenkins Eklentisini bu XML dosyasını kullanacak şekilde yapılandırın . Sonuçlar kontrol panelinde mevcut olacaktır.

Şimdi, NUnit'i nasıl çağıracağınız size kalmış. Bunu yaptığımız yol şuydu: Jenkins işi NAnt hedefini çalıştırır, NUnit test takımını çalıştırır.

Jenkins işlerini kesinleştirme üzerinde çalışacak ve / veya belirli bir zamanda planlanacak şekilde yapılandırabilirsiniz.


Neredeyse bunun için gittim, ancak NUnit eklentisini bir ardışık düzen / iş akışından çalıştıramadım. Bunun yerine iyi çalışan XUnit eklentisini kullandım.
demoncodemonkey

4

Ralph Willgoss'un çözümü iyi çalışıyor, ancak onu harika kılmak için 2 şeyi değiştirdim:

a) DLL dosyası yerine doğrudan bir NUnit projesi kullandım. Bu, daha fazla derleme eklemeyi veya testi NUnit GUI'de yapılandırmayı daha kolay hale getirir.

b) Bir test başarısız olduğunda derlemenin başarısız olmasını önlemek için toplu işleme bir satır daha ekledim:

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

Bahsedilen NUnit Eklentisi , bir test başarısız olduğunda, tam olarak istediğim şey olan, yapıyı UNSTABLE olarak işaretler . Sarı bir nokta ile gösterilir.


3
Neden olur değil birim test başarısız olursa inşa başarısız istiyor? Başarısız olan test, bir konuşlandırmaya devam etmek istemediğinizi göstermemeli mi?
Kirk Woll

1
Ayrıca gecelerimi jenkins ile oluşturuyorum ve diğer her şeyi test edebilmek için derlerlerse başarısız olmalarını istemiyorum. "kararsız" durumu bana her şeyin olması gerektiği gibi gitmediğine dair bir ipucu veriyor. Kararsız. Bir sürüm yapısı kararsızsa onu dağıtmayacağım.
JCH2k

2

Bence onu dağıtmamak için yapıyı geçmediğinde başarısız olmanın daha iyi olacağını düşünüyorum. Bunun gibi bir şey yapın:

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%

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


Bu, ilk satırın tek başına yapabileceğinden daha fazlasını yapıyor mu? ben öyle düşünmüyorum. nunit-console.exe değeri! = 0 döndürürse, yapı yine de başarısız olur ve bu, bir test başarısız olursa yapar.
JCH2k

Jenkins işimde nunit-console.exe'yi çağırdıktan sonra bazı komutlarım olduğunu söylemeyi unuttum. Jenkins sadece son komut olan ERRORLEVEL'i düşünüyor, bu yüzden benim için çalışmıyordu.
Akira Yamamoto

Bu, yayınlama adımının faydalarını engelliyor mu? Keşke eklentinin başarısız test yapılandırmasında "" olarak basit bir işaret yapısı olsaydı.
Tommy Holman

1

Jenkins'in bunu destekleyecek eklentileri var. Kesin konfigürasyon, proje kurulumunuza oldukça bağlı olacaktır. NUnit, MSBuild, nAnt vb. İçin özel eklentiler vardır. Eklentiler sayfasına bakarak başlayın, ancak anlaşılması çok zor olmamalı.


1

Bu, OpenCover'ı Jenkins'te vstest ile çalıştırmak için benim çözümüm :

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

Her test dll'si kendi işleminde yürütülür çünkü tüm test dll'lerini tek bir işlemde (derleme yüklemeli sorunlar) yürütmekte zorluk yaşadık.


0

.Net Core için, aşağıdaki komut dosyasıyla "kabuk yürütme" oluşturma adımı eklemek yeterlidir:

#!bash -x

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

Bundan sonra, test sonuçlarını görünür kılmak için "MSTest test sonucu raporunu yayınla" derleme sonrası eylemi ekleyin.

Varsayılan test raporlarının yolu, **/*.trxüretilen tüm .trxdosyalar olmalıdır ve yayınlanacaktır .

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.