VSTest'ten Microsoft.Testing.Platform'a (MTP) geçiş

Bu makalede VSTest'ten MTP'ye nasıl geçiş yapılacağını öğreneceksiniz.

Bu makale, geçiş adımlarına ve argüman eşlemesine odaklanır.

Yine de bir platform seçmeniz gerekiyorsa Test platformlarına genel bakış ile başlayın.

Modların ayrıntılı davranışına ihtiyacınız varsa, dotnet test'ye bakın.

Platform ve uzantı komut satırı seçeneklerinin tek bir listesine ihtiyacınız varsa bkz. MTP CLI seçenekleri başvurusu.

MTP'yi kullanmayı kabul etme

Geçişin ilk adımı MTP'yi kullanmayı kabul etmektir.

Tüm test çerçeveleri için çözümdeki tüm test projelerine ekleyin <OutputType>Exe</OutputType> . Bundan sonra çerçeveye özgü yönergeleri izleyin.

MSTest

MTP, 3.2.0 ile başlayan MSTest tarafından desteklenir. Ancak, en son kullanılabilir MSTest sürümüne güncelleştirmenizi öneririz.

Kabul etmek için, <EnableMSTestRunner>true</EnableMSTestRunner>'yi PropertyGroup altına Directory.Build.props dosyasında ekleyin.

Uyarı

MSTest.Sdk kullanılırken, <UseVSTest>true</UseVSTest> belirtilmedikçe varsayılan olarak MTP kullanılır.

NUnit

MTP, 5.0.0 ile başlayan NUnit3TestAdapter tarafından desteklenir.

Kabul etmek için, <EnableNUnitRunner>true</EnableNUnitRunner>'yi PropertyGroup altına Directory.Build.props dosyasında ekleyin.

xUnit.net

MTP, xunit.v3 ile başlayarak desteklenir.

Kabul etmek için, <UseMicrosoftTestingPlatformRunner>true</UseMicrosoftTestingPlatformRunner>'yi PropertyGroup altına Directory.Build.props dosyasında ekleyin.

dotnet test

.NET 9 SDK ve önceki sürümler için giriş yap

.NET 9 SDK ve önceki sürümlerde, için MTP için dotnet test desteği yoktur. Destek, VSTest altyapısının üzerine kurulmuştur. Bunu kullanmak için <TestingPlatformDotnetTestSupport>true</TestingPlatformDotnetTestSupport> dosyasındaki bir PropertyGroup altına Directory.Build.props ekleyin.

Önemli

MTP desteğini bu modda çalıştırırken, -- eklemeniz dotnet test gerekir. Bu ekleme, bağımsız değişkenleri yeni platform bağımsız değişkenlerinden ayırır. Örneğin, dotnet test --no-build -- --list-tests.

.NET 10 SDK ve üzeri için katılmayı tercih et.

.NET 10 SDK'dan başlayarak MTP için native desteği vardır. Bunu kullanmak için Microsoft.Testing.Platform test çalıştırıcısını global.json'de belirtmeniz gerekir.

{
  "test": {
    "runner": "Microsoft.Testing.Platform"
  }
}

Önemli

Bu modda, ekstra -- artık kullanılmaz.

Çağrıları güncelle dotnet test

komut satırı seçenekleri dotnet test iki kategoriye ayrılır: derlemeyle ilgili bağımsız değişkenler ve testle ilgili olanlar.

Derlemeyle ilgili parametreler test platformuyla ilgili olmadığı için yeni platform için güncelleştirilmesi gerekmez. Derlemeyle ilgili argümanlar burada listelenmiştir.

  • -a|--arch <ARCHITECTURE>
  • --artifacts-path <ARTIFACTS_DIR>
  • -c|--configuration <CONFIGURATION>
  • -f|--framework <FRAMEWORK>
  • -e|--environment <NAME="VALUE">
  • --interactive
  • --no-build
  • --nologo
  • --no-restore
  • -o|--output <OUTPUT_DIRECTORY>
  • --os <OS>
  • -r|--runtime <RUNTIME_IDENTIFIER>
  • -v|--verbosity <LEVEL>

Testle ilgili bağımsız değişkenler VSTest'e özeldir ve bu nedenle yeni platformla eşleşecek şekilde dönüştürülmesi gerekir. Aşağıdaki tabloda VSTest bağımsız değişkenleri ile yeni platform arasındaki eşleme gösterilmektedir:

VSTest bağımsız değişkeni Yeni platform argümanı
--test-adapter-path <ADAPTER_PATH> MTP ile ilgili değil
--blame MTP ile ilgili değil
--blame-crash --crashdump ( Kilitlenme dökümü uzantısı gerektirir)
--blame-crash-dump-type <DUMP_TYPE> --crashdump-type ( Kilitlenme dökümü uzantısı gerektirir)
--blame-crash-collect-always Desteklenmez
--blame-hang --hangdump ( Kilitlenme bilgi dökümü uzantısı gerektirir)
--blame-hang-dump-type <DUMP_TYPE> --hangdump-type ( Kilitlenme bilgi dökümü uzantısı gerektirir)
--blame-hang-timeout <TIMESPAN> --hangdump-timeout ( Kilitlenme bilgi dökümü uzantısı gerektirir)
--collect <DATA_COLLECTOR_NAME> Veri toplayıcıya bağlıdır
-d\|--diag <LOG_FILE> --diagnostic
--filter <EXPRESSION> Seçilen test çerçevesine bağlıdır
-l\|--logger <LOGGER> Günlük kaydı sistemine bağlıdır
--results-directory <RESULTS_DIR> --results-directory <RESULTS_DIR>
-s\|--settings <SETTINGS_FILE> Seçilen test çerçevesine bağlıdır
-t\|--list-tests --list-tests
-- <RunSettings arguments> --test-parameter ( VSTestBridge tarafından sağlanır)

--collect

--collect vsTest'te herhangi bir veri toplayıcı için genel bir genişletilebilirlik noktasıdır. MTP'nin genişletilebilirlik modeli farklıdır ve tüm veri toplayıcıları tarafından kullanılacak böyle bir merkezi bağımsız değişken yoktur. MTP ile her veri toplayıcı kendi komut satırı seçeneğini ekleyebilir. Örneğin, VSTest aracılığıyla Microsoft CodeCoverage çalıştırmak aşağıdakine benzer olabilir:

dotnet test --collect "Code Coverage;Format=cobertura"

MTP ile bu şu hale gelir:

dotnet test --coverage --coverage-output-format cobertura

Önemli

Daha önce açıklandığı gibi, VSTest'i temel alan dotnet test ile MTP kullanılırken, platforma geçmesi amaçlanan bağımsız değişkenlerin öncesinde ek -- gereklidir. Yani, bu olur dotnet test -- --coverage --coverage-output-format cobertura.

--filter

--filter VSTest tabanlı filtredir.

MSTest ve NUnit, MTP ile çalışırken bile aynı filtre biçimini destekler.

xUnit.net, MTP ile çalışırken aynı filtre biçimini desteklemez. VSTest tabanlı filtreden, aşağıdaki komut satırı seçenekleri kullanılarak sağlanan xunit.v3'teki yeni filtre desteğine geçmeniz gerekir.

xUnit.net'e özgü seçenekler:

  • --filter-class
  • --filter-not-class
  • --filter-method
  • --filter-not-method
  • --filter-namespace
  • --filter-not-namespace
  • --filter-trait
  • --filter-not-trait
  • --filter-query

Daha fazla bilgi için xUnit.net için Microsoft.Testing.Platform belgelerine ve xUnit.net için Sorgu Filtresi Dili'ne bakın.

Tavsiye

Çözümünüz farklı filtre söz dizimleri (örneğin, MSTest ve xUnit.net) kullanan test çerçevelerini karıştırırsa, MSBuild özelliğini kullanarak çerçeveye TestingPlatformCommandLineArguments özgü bağımsız değişkenleri koşullu olarak yönlendirebilirsiniz. Ayrıntılar için bkz. Karma test çerçeveleri veya uzantıları olan çözümler.

--logger

VSTest'te genellikle "günlükçü" olarak adlandırılan şey, MTP'de "muhabir" olarak adlandırılır. MTP'de kayıtlar açıklıkla sadece tanı amaçlı kullanım içindir.

Benzer şekilde --collect, --logger VSTest'te herhangi bir kayıt cihazı (ve MTP bağlamında herhangi bir muhabir) için genel bir genişletilebilirlik noktasıdır. Her MTP muhabiri kendi komut satırı seçeneğini ekleyebilir ve bu nedenle VSTest'in --loggergibi merkezi bir komut satırı seçeneği yoktur.

En yaygın kullanılan VSTest günlükçülerinden biri TRX günlükçüdür. Bu logger genellikle aşağıdaki şekilde çağrılır:

dotnet test --logger trx

MTP ile komutu şu hale gelir:

dotnet test --report-trx

Önemli

--report-trx kullanmak için Microsoft.Testing.Extensions.TrxReport NuGet paketinin yüklü olması gerekir.

Önemli

Daha önce açıklandığı gibi, VSTest'i temel alan dotnet test ile MTP kullanılırken, platforma geçmesi amaçlanan bağımsız değişkenlerin öncesinde ek -- gereklidir. Yani, bu olur dotnet test -- --report-trx.

--settings

VSTest --settings test çalıştırması için bir RunSettings dosyası belirtmek amacıyla kullanılır. RunSettings, çekirdek MTP tarafından desteklenmez ve yerine daha modern testconfig.json bir yapılandırma dosyası kullanılır. Ancak MSTest ve NUnit, MTP çalıştırılırken eski RunSettings'i desteklemeye devam eder ve --settings hala desteklenir.

vstest.console.exe

vstest.console.exe komutunu doğrudan kullanıyorsanız, bunu dotnet test komutuyla değiştirmenizi öneririz.

Test Gezgini

Visual Studio veya Visual Studio Code Test Gezgini'ni kullanırken MTP desteğini etkinleştirmeniz gerekebilir.

Visual Studio

Visual Studio Test Gezgini, 17.14 sürümünden itibaren MTP'i destekler. Önceki bir sürümü kullanıyorsanız Visual Studio'nuzu en son sürüme güncelleştirmeniz gerekebilir.

Visual Studio Code

C# DevKit ile Visual Studio Code MTP'i destekler.

Azure DevOps

Azure DevOps görevleri kullanırken, hangi görevi kullandığınıza bağlı olarak işlem hattınızı MTP kullanacak şekilde güncelleştirmeniz gerekebilir.

VSTest görevi

Azure DevOps'ta VSTest görevini kullanıyorsanız, bunu .NET Core göreviyle değiştirebilirsiniz.

.NET Core CLI ile ilgili görev

  • Özel arguments görev için verildiğinde, dotnet test geçişi için aynı yönergeleri izleyin.

  • DotNetCoreCLI görevini .NET 10 SDK ve üzeri için yerel MTP deneyimine katılmadan global.json dosyası aracılığıyla kullanıyorsanız, görev arguments görevi, istenen TRX raporunun yanı sıra işaret ettiği sonuç dizinine doğru şekilde işaret etmek için ayarlamanız gerekir. Örneğin:

    - task: DotNetCoreCLI@2
      displayName: Run unit tests
      inputs:
        command: 'test'
        arguments: '-- --report-trx --results-directory $(Agent.TempDirectory)'
    

VSTest ile MTP arasındaki davranış farklılıkları

Sıfır test çalıştırma

Test derlemesi sıfır test çalıştırdıysa VSTest bunu tolere eder ve başarılı bir şekilde çıkar. Ancak, MTP çıkış kodu 8 ile başarısız olur. Bu sorunu geçici olarak gidermenin birden çok yolu vardır:

  • Testlerinizi çalıştırırken --ignore-exit-code 8 simgesini yerleştirin.

  • Belirli bir test projesi için bu çıkış kodunu yoksaymak istiyorsanız, proje dosyasına aşağıdakileri ekleyin:

    <PropertyGroup>
      <TestingPlatformCommandLineArguments>$(TestingPlatformCommandLineArguments) --ignore-exit-code 8</TestingPlatformCommandLineArguments>
    </PropertyGroup>
    
  • Ortam değişkenini TESTINGPLATFORM_EXITCODE_IGNORE kullanın.

Console.InputEncoding koruması

Testlerinizi kod sayfasının açıkça değiştirildiği bir konsolda çalıştırırsanız (örneğin, Azure DevOps kod sayfası UTF8'e karşılık gelen 65001 olarak ayarlanır), davranış VSTest ile MTP arasında farklı olabilir.

  • MTP ile bu kodlama her zaman korunur.
  • VSTest yalıtım modunda çalışmıyorken (vstest.console'un varsayılan davranışı), bu kodlama MTP'ye benzer şekilde korunur.
  • VSTest yalıtım modunda çalışırken (varsayılan davranışı dotnet test), bu kodlama testleri çalıştıran işlem olan testhost'ta korunmaz.

Tavsiye

VsTest yalıtım moduyla kodlamanın korunmama nedeni, testhost işleminin ile CreateNoWindow = truebaşlatılmasıdır. Bu nedenle özgün konsola bağlı değildir.

Başka bir alt işlem başlatan ve standart çıkışını yeniden yönlendiren bir teste sahipseniz, aşağıdakilerin tümü geçerliyse sorunlarla karşılaşabilirsiniz:

  • Konsol kod sayfası 65001 (UTF8) olarak ayarlanır. Ci'de bu durum söz konusu olabilir ancak genellikle yerel olarak geçerli değildir. CI'dekine benzer bir yerel davranış elde etmek için testleri çalıştırmadan önce komutunu çalıştırın chcp 65001 .
  • Alt işlem UTF8 olmayan kodlama ile başlatılır. Kendi testiniz de CreateNoWindow = true ayarlarsa bu durum oluşabilir.

Bu durum özellikle alt işlemin .NET Framework'teki önceki senaryoda edinebileceği UTF8 BOM (Byte-Order-Mark) baytını görmeyi beklemediği durumlarda sorunludur.

Bu davranış farkı özellikle BOM baytı için sorunlu olabileceğinden, geçici çözüm derleme başlatma sırasında InputEncoding'i BOM'suz UTF8 olarak ayarlamaktır.

Console.InputEncoding = new UTF8Encoding(encoderShouldEmitUTF8Identifier: false);

Bu durum için farklı bir geçici çözüm, standart girişi yeniden yönlendiren alt işlemler için CreateNoWindow = true kullanmamaktır.