Sorun, tek başına kırmızı bir derlemenin görünmesi değil; bunun yeni bir gerilemeden mi, aralıklı bir testten mi yoksa araştırma için gerekli kanıtları ortadan kaldıran test konağı çökmesinden mi kaynaklandığını bilmektir. .NET Blog, Microsoft.Testing.Platform veya MTP'nin test raporlarını yalnızca uzun bir günlük listesi göstermek yerine geliştiriciler, gözden geçirenler ve sürekli tümleştirme araçları için nasıl daha yararlı hâle getirebileceğini açıklıyor.
Bu uygulamalar GitHub Actions veya Azure DevOps kullanan ve hata bilgilerinin birleştirme isteğinde karar verme noktasına ulaşmasını isteyen ekipleri hedefliyor. Platform ayrıca tek bir çalıştırmadan birden fazla rapor biçimi üretmeye ve programların, panoların ve geliştirme araçlarının istikrarlı biçimde tüketebileceği yapılandırılmış çıktılar sağlamaya olanak tanıyor.
Gerileme ile aralıklı hata arasında ayrım yapmak için derleme geçmişini kullanın
Azure DevOps, test kanıtlarını Tests sekmesinde zaten gösteriyor; ancak raporlayıcıya geçmiş aralığı geçirmek her hataya bağlam ekliyor. --report-azdo-flaky-history 14 seçeneği kullanıldığında platform, son 14 gün içindeki işlem hattı geçmişini sorguluyor ve aralıklı olarak başarısız olan test ile benzer bir geçmişi bulunmayan testi ayırt ediyor.
Aralıklı test [flaky: failed 3/20 in last 14d] etiketiyle görünebilirken, bu kayda sahip olmayan hata [REGRESSION] etiketi alıyor. Bu, gözden geçirenin araştırmaya doğru yoldan başlamasına yardımcı oluyor: geçmişi olmayan hata, olası bir gerileme olarak acil ilgi gerektirirken tekrarlanan hata bilinen geçmişinden ele alınıyor.
Ekip sürekli tümleştirmenin bu davranışı değiştirmesini isterse --report-azdo-demote-known-flaky seçeneği, aralıklı olduğu bilinen hataları uyarıya dönüştürürken gerilemeleri hata olarak bırakıyor. Ancak kaynak, kararın açık olması gerektiğini vurguluyor: Geçmişi yalnızca gözden geçireni yönlendirmek için mi kullanmak istiyoruz, yoksa hata önem düzeyini otomatik olarak değiştirmesini mi istiyoruz? testfx işlem hattında geçmiş yorumları kullanılmış, ancak tüm hata durumları derlemeyi engellemeye devam etmiştir.
Aynı geçmiş, --report-azdo-slow-test-history aracılığıyla yavaş testleri saptamak için de kullanılıyor. Seçenek, her testi önceki performansıyla karşılaştırıyor; tek bir soğuk çalıştırmanın hatalı bir uyarı oluşturmasını önlemek için ayarlanabilir bir katsayı ve asgari çalıştırma sayısı kullanıyor.
Test konağı çöktüğünde kanıtları koruyun
TRX biçimindeki sonuçlar çalıştırmanın sonunda serileştiriliyordu; bu nedenle ciddi bir çökme tüm raporun kaybolmasına yol açabiliyordu. Artık sonuçlar üretildikçe diske yazılıyor ve çökme dökümü uzantısıyla birlikte, konak durduğunda kısmi rapor tamamlanabiliyor:
dotnet test --report-trx --crashdump
Bunun sonucunda tamamlanan tüm testleri ve çökme sırasında çalışmakta olan testlerin listesini içeren geçerli bir TRX dosyası oluşuyor. Uzantı ayrıca her testin başlangıcını ve bitişini kaydeden .crash.sequence.log uzantılı bir dosya yazıyor; bu da birden fazla test paralel çalıştırıldığında bile başlayıp tamamlanmayan testi belirlemeye yardımcı oluyor.
İşlem ekleri de kapsıyor. Çökme dökümleri, durma yorumları ve test uzantısı dosyaları, yol Windows MAX_PATH sınırını aştığında .NET Framework'te artık sessizce yok sayılmıyor. Bir ek kopyalanamazsa bu durum yalnızca TRX dosyasında belirtilmek yerine konsolda gösteriliyor. Sonuç olarak tamamlanmamış çalıştırma açıkça tamamlanmamış olarak görünüyor ve eksik kanıtları gizleyen yeşil bir rapor izlenimi vermiyor.
Rapor biçimini tüketiciye göre seçin
Tek bir çalıştırma, ayrı bir dönüştürme adımı olmadan birden fazla biçimi etkinleştirebilir. TRX biçimi .NET araçlarına, HTML doğrudan incelemeye, JUnit XML ve CTRF JSON ise panolara ve teknolojiler arası otomasyona uygundur. CTRF, .NET sonuçlarını diğer dillerin sonuçlarıyla birleştirmek için ortak bir JSON şeması sunar.
Sürekli tümleştirme sistemleri sonuç görünümlerinde TRX ve JUnit biçimlerini okurken HTML ve CTRF, indirilebilen veya panolarda kullanılabilen dosyalar olarak görünür. Azure DevOps'ta --report-azdo-upload-artifacts files seçeneği, sonuç kanıtı dosyalarını otomatik olarak yükleyebilir. Ayrıca sonuçların birden fazla çalışma zamanını hedefleyen projelerde çakışmaması için {asm} ve {tfm} gibi yer tutucularla birlikte --report-<format>-filename seçeneği kullanılarak dosyalar adlandırılmalıdır.
Çıktıları kararlı ve otomasyona uygun hâle getirin
--list-tests json seçeneği, keşfedilen testleri ve kaynak konumlarını açıklayan, şeması sürümlendirilmiş bir belge sağlar. Bu, sürümler arasında değişebilen konsol metnini ayrıştırmak yerine test seçimi, değişiklik etkisi analizi ve geliştirme ortamlarıyla tümleştirme için kararlı bir giriş noktasıdır.
MTP çıktıları aracı ve dil modeli ortamlarına uyarlanır; başlık çubuğunu, ANSI karakterlerini ve ilerleme hareketini gizler ve varsayılan olarak yalnızca başarısız testlerin stdout ve stderr çıktılarını gösterir. Davranış NO_COLOR ile --ansi ve --progress seçenekleri üzerinden denetlenebilir.
Raporlama politikasını sabitleyin ve uyumluluğu doğrulayın
Makale, tek bir test projesinde MTP 2.3 veya daha yeni bir sürümün denenmesini, ardından GitHub Actions'ta --report-gh ya da Azure DevOps'ta --report-azdo seçeneğinin etkinleştirilmesini öneriyor. Politika seçildikten sonra ayarlar depo içindeki testconfig.json dosyasına kaydedilerek yerel çalıştırmaların ve CI işlemlerinin aynı raporları üretmesi sağlanıyor. Tüm test projelerine ortak ayarlar uygulamak için Directory.Build.props kullanılabilir veya uzantıların kararlı kümesini etkinleştirmek için AllMicrosoft profili kullanılabilir; JUnit ve CTRF isteğe bağlı kalır.
MSTest.Sdk kullanmayan ekipler, raporlayıcı paketlerinin sürümleri ile test çerçevesinin hedeflediği MTP sürümünün eşleştiğini doğrulamalıdır. MTP 2.x desteği MSTest.TestAdapter 4.0.0, NUnit3TestAdapter 6.0.1, TUnit 1.7.16, YoloDev.Expecto.TestSdk 0.16.0 ve xunit.v3 4.0'ın önizleme sürümlerine kadar uzanır. Çözüm ayrıca MTP ve VSTest projelerinin birlikte kullanılmasını desteklemez; bu nedenle MTP çalıştırmasına katılım depo düzeyinde ayarlanmalıdır.
Azure DevOps geçmiş seçenekleri SYSTEM_ACCESSTOKEN: $(System.AccessToken) belirtecini gerektirir. Bu belirteç olmadan çalıştırma devam eder, ancak geçmiş yorumları atlanır. Mevcut işlem hatlarında test sonucu yayımlama ve dosya yayımlama görevleri, karşılık gelen MTP seçenekleriyle değiştirilebilir; ancak kod kapsamı yayımlama bunun yerine geçmez. Bu nedenle PublishCodeCoverageResults@2 korunmalıdır. Ayrıca doğrudan yayımlama ile PublishTestResults@2 birlikte etkinleştirilmemelidir; çünkü aynı derleme için iki ayrı test çalıştırması oluşturur.