MSTest 4.4, test projelerinin uygulamanın üretimde kullanabileceği dağıtım modelinin aynısını kullanarak çalıştırılmasını; test kaynağının oluşturulmasını, Native AOT ve kırpmayı etkinleştirmeyi mümkün kılar. Amaç, normal yönetilen test çalıştırmasını değiştirmek değil, uygulama yayımlanmadan önce önceden derleme ve kullanılmayan kodun silinmesiyle ilgili sorunları ortaya çıkaran yerel bir yol eklemektir.
Principal Software Engineer Amaury Levé’ye göre MSTest.Sdk/4.4.0 kullanılması, net10.0 hedeflenmesi ve PublishAot=true olarak ayarlanması MSTest kaynak üretimini ve yerel yürütülebilir dosya yolunu etkinleştirir. MSTest.Sdk, varsayılan olarak Microsoft Testing Platform’u veya MTP’yi kullanır. Hâlâ VSTest kullanan projeler, MTP’ye geçiş yönergelerini incelemelidir; çünkü komut satırı seçenekleri, CI entegrasyonu ve desteklenen bazı .runsettings girdileri farklıdır.
Uygulamada ne değişir?
Proje yapılandırıldıktan sonra testler, uygulamanın hedeflediği işletim sistemi ve mimari için yayımlanmalıdır. Kaynakta linux-x64 tanımlayıcısı kullanılarak bir örnek verilir; bu değer win-x64 veya osx-arm64 gibi değerlerle değiştirilebilir. Yayımdan sonra oluşturulan yürütülebilir dosya doğrudan çalıştırılır; Windows’ta ise .exe uzantısıyla çalıştırılır.
Bu yol, Assembly.GetTypes() çağrısı gibi derlemenin kapsamlı yansıma yoluyla incelenmesine olan bağımlılığı azaltır; ayrıca desteklenen testleri oluşturup çağırmak için oluşturulmuş öznitelikler ve temsilciler kullanır. Ancak kaynak üretimi Reflection’ın tamamen ortadan kalktığı anlamına gelmez; varsayılan ReflectionFree modu bazı yansıma tabanlı geri dönüş yollarını korur. Uyumluluk sorunları incelenirken, yansıma tabanlı çalıştırma sürdürülürken keşfedilen test üyelerini korumak için MSTestSourceGenMode=Rooting kullanılabilir.
Genişletmeden önce sınırlı bir CI yolu
Pratik öneri, günlük geri bildirim için hızlı yönetilen test çalıştırmasını korumak, ardından dağıtım yoluyla doğrudan ilgili tek bir test projesi seçerek CI içinde Native AOT denemesi eklemektir. İki yol üç açık açıdan karşılaştırılmalıdır:
- Tam olarak aynı sayıda test keşfedilmesi.
- Testler için aynı sonuçların alınması.
- Yayımlama ve yerel çalıştırma süresinin, test yürütme süresinden ayrı kaydedilmesi.
Denemeye zamanlanmış bir görevde veya sürüm doğrulama aşamasında başlanması; yalnızca sağladığı sinyal ek yayımlama ve çalıştırma maliyetine değiyorsa her birleştirme isteğine taşınması tercih edilir. Ayrıca serileştirme, bağımlılık ekleme, yapılandırma bağlama, Reflection’a dayalı eklentiler veya ekiplerin Native AOT ile uyumluluğunu kanıtlaması gereken bir kitaplık gibi dağıtım açısından hassas yolları test eden bir proje seçilmelidir. Yalnızca basit hesaplama testlerinden oluşan bir proje, uygulamanın gerçek hazırlığı hakkında fazla kanıt sunmaz.
Kabul kapılarına dönüştürülmesi gereken kısıtlamalar
Testlerin bir bölümü başarılı olabilir ve bazı sınıflar kaydedilmediği hâlde işlem başarıyla tamamlanabilir. Bu durum, örneğin test sınıfı [TestClass] özniteliğini doğrudan bildirmek yerine yalnızca özniteliği miras aldığında ya da sınıf erişilebilir olmadığında, yerel olduğunda, statik olduğunda, genel olduğunda veya soyut olduğunda meydana gelir. Kaynak, MSTEST0069 tanısının bu durumlardan birini ortaya çıkarmaya yardımcı olduğunu belirtir. Bu nedenle test sayısının eşleşmesi, göz ardı edilebilecek bir not değil, sürüm koşulu olmalıdır.
Diğer kısıtlamalar arasında genel test yöntemleri veya ref, out ya da in parametrelerini kullanan yöntemler ile [AssemblyFixtureProvider] aracılığıyla belirli statik parça kalıplarının desteklenmemesi yer alır. Ayrıca bazı MSTest SDK entegrasyonları, MTP uzantıları ve CI raporları Native AOT yolunda kullanılamaz; buna karşılık makaleye göre TRX ve Code Coverage desteği kullanılabilir olmaya devam eder. Bu nedenle analizör uyarıları ve derleme tanıları, susturulacak uyarılar olarak değil, geçiş kapıları olarak ele alınmalıdır.
Bu yaklaşım neden önemlidir?
Yönetilen test ve Native AOT yolu iki farklı soruya yanıt verir: İlki geliştirme döngüsünü hızlandırır; ikincisi ise testlerin, uygulamanın kullanacağı dağıtım modeli içinde çalışıp çalışamayacağını doğrular. Bu, nihai üretim parçasının kapsamlı bir testi anlamına gelmez; yapılandırmalar, işletim sistemi, mimari, dış hizmetler ve paketleme farklılık gösterebilir. Ancak test ile uygulama arasındaki kırpma ve önceden derleme modelinin farklı olmasını önemli bir değişken olarak ortadan kaldırır.
Performans artışı garanti değildir ve temel gerekçe olmamalıdır. Kaynak üretimi sayesinde keşif ve başlatma süresi azalabilir; ancak yürütme süresi, işlemin başlatılması, yayımlama ve kalan Reflection toplam süreye hâkim olabilir. Buradaki editoryal değerlendirme, hız kazanımı sınırlı olsa bile denemenin temel değerinin testin dağıtımla uyumunu artırmak olduğudur. Yaklaşım geri alınabilir olmaya devam eder: Yolun maliyeti sağladığı güveni aşarsa sıklığı azaltılabilir, seçilen proje değiştirilebilir veya yönetilen test grubunu aksatmadan deneme durdurulabilir.