Microsoft extinde MSTest 4.4 cu suport pentru publicarea și rularea proiectelor de test ca executabile Native AOT. Ideea este simplă: dacă aplicația finală este compilată ahead-of-time și supusă trimming-ului, testarea exclusiv în modul managed poate rata defecte care apar doar în artefactul publicat.

Native AOT elimină codul nefolosit și limitează anumite forme de reflecție și generare dinamică de cod. Din acest motiv, o aplicație poate trece toate testele obișnuite și totuși să eșueze după publicare. Microsoft dă ca exemplu serializarea System.Text.Json bazată pe reflecție, care poate funcționa într-un test managed, dar poate arunca excepții într-un build Native AOT dacă nu există metadata generată la compilare.

Source generation pentru descoperirea testelor

Noul mecanism MSTest folosește source generation pentru a înregistra clasele de test, atributele și delegatele necesare apelării metodelor înainte ca trimming-ul să elimine cod. Testele pot rămâne scrise în stilul obișnuit, cu [TestClass] și [TestMethod], fără ca dezvoltatorii să rescrie întreaga suită.

Configurația minimă folosește MSTest.Sdk 4.4 și proprietatea PublishAot=true. Microsoft Testing Platform este motorul implicit pentru MSTest.Sdk, iar proiectele care folosesc încă VSTest trebuie să țină cont de diferențele de integrare și configurare.

Microsoft nu recomandă înlocuirea testelor clasice

Mesajul este explicit: testele Native AOT nu trebuie să înlocuiască rulările managed rapide. Microsoft recomandă păstrarea lane-ului existent din CI și adăugarea inițială a unui singur proiect reprezentativ care este publicat și executat nativ.

Un criteriu important este paritatea numărului de teste. Dacă source generator-ul nu poate înregistra anumite clase sau metode, executabilul nativ ar putea termina cu succes, dar să fi rulat mai puține teste. Din acest motiv, Microsoft recomandă verificarea explicită a numărului de teste descoperite și a rezultatelor între cele două lane-uri.

Unde are cea mai mare valoare

Native AOT testing este util mai ales pentru componente care folosesc serializare, dependency injection, configuration binding, plugin-uri bazate pe reflecție sau biblioteci a căror compatibilitate AOT trebuie demonstrată. Pentru proiectele formate doar din teste unitare simple, valoarea suplimentară poate fi redusă.

MSTest 4.4 păstrează suport pentru TRX și Code Coverage în acest scenariu, dar nu toate extensiile MTP și integrările CI sunt disponibile. Microsoft recomandă tratarea warning-urilor și diagnosticelor de build ca bariere de migrare, nu ca mesaje ce trebuie ignorate.

Sursa: .NET Blog – 3 septembrie 2026