MSTest 4.4 позволяет запускать проекты тестов с использованием той же модели развертывания, которую приложение может использовать в рабочей среде, благодаря генерации исходного кода тестов и включению Native AOT и тримминга. Эта идея не направлена на замену обычного запуска управляемых тестов, а предполагает добавление нативного пути, выявляющего проблемы, связанные с предварительной компиляцией и удалением неиспользуемого кода до выпуска приложения.
По словам Amaury Levé, Principal Software Engineer, использование MSTest.Sdk/4.4.0 с целевой платформой net10.0 и параметром PublishAot=true активирует генерацию исходного кода MSTest и путь к нативному исполняемому файлу. MSTest.Sdk по умолчанию использует Microsoft Testing Platform, или MTP. Проектам, которые всё ещё используют VSTest, следует ознакомиться с рекомендациями по переходу на MTP, поскольку параметры командной строки, интеграция с CI и некоторые поддерживаемые элементы .runsettings отличаются.
Что меняется на практике?
После настройки проекта тесты следует развернуть для той же операционной системы и архитектуры, на которые ориентировано приложение. В источнике приведён пример с идентификатором linux-x64, который можно заменить такими значениями, как win-x64 или osx-arm64. После развертывания полученный исполняемый файл запускается напрямую или с расширением .exe в Windows.
Этот путь снижает зависимость от полного рефлексивного сканирования сборки, например от вызова Assembly.GetTypes(), а также использует сгенерированные атрибуты и делегаты для создания и вызова поддерживаемых тестов. Однако генерация исходного кода не означает полного отсутствия Reflection: режим ReflectionFree, используемый по умолчанию, сохраняет некоторые резервные рефлексивные пути. При расследовании проблем совместимости можно использовать MSTestSourceGenMode=Rooting, чтобы сохранить обнаруженные члены тестов и продолжить рефлексивное выполнение.
Ограниченный путь CI перед расширением
Практическая рекомендация заключается в том, чтобы сохранить быстрый запуск управляемых тестов для ежедневной обратной связи, а затем выбрать один проект тестов, непосредственно связанный с путем развертывания, и добавить эксперимент Native AOT в CI. Следует сравнить оба пути по трём чётким аспектам:
- обнаруживается абсолютно одинаковое количество тестов;
- получаются одинаковые результаты тестов;
- время развертывания и нативного запуска регистрируется отдельно от времени выполнения тестов.
Предпочтительно начать эксперимент в запланированном задании или на этапе проверки выпуска, а затем перенести его на каждый запрос на слияние только в том случае, если предоставляемый им сигнал оправдывает дополнительные затраты на развертывание и запуск. Также следует выбрать проект, тестирующий чувствительные к развертыванию пути, такие как сериализация, внедрение зависимостей, связывание конфигурации, расширения, зависящие от Reflection, или библиотеку, совместимость которой с Native AOT необходимо подтвердить. Проект, содержащий только простые вычислительные тесты, не даст существенных доказательств фактической готовности приложения.
Ограничения, которые следует превратить в критерии приемки
Часть тестов может завершиться успешно, а процесс — завершиться без ошибок, даже если некоторые классы не были зарегистрированы. Это происходит, например, когда класс теста наследует атрибут [TestClass], а не объявляет его непосредственно, или когда класс недоступен, является локальным для файла, статическим, открытым универсальным или абстрактным. В источнике указано, что диагностика MSTEST0069 помогает обнаружить один из таких случаев. Поэтому совпадение количества тестов должно быть условием выпуска, а не замечанием, которое можно проигнорировать.
К другим ограничениям относятся открытые методы тестов или методы, использующие параметры ref, out или in, а также отсутствие поддержки некоторых шаблонов статических частей через [AssemblyFixtureProvider]. Кроме того, некоторые интеграции MSTest SDK, расширения MTP и отчёты CI недоступны в пути Native AOT, тогда как поддержка TRX и Code Coverage, согласно статье, сохраняется. Поэтому к предупреждениям анализатора и диагностике сборки следует относиться как к воротам перехода, а не как к предупреждениям, которые нужно подавить.
Почему этот подход важен?
Управляемое тестирование и путь Native AOT отвечают на два разных вопроса: первый ускоряет цикл разработки, а второй проверяет, могут ли сами тесты работать в рамках модели развертывания, которую будет использовать приложение. Это не равнозначно всестороннему тестированию конечного производственного артефакта: настройки, операционная система, архитектура, внешние службы и упаковка могут отличаться. Однако такой подход устраняет важную переменную — различие модели тримминга и предварительной компиляции между тестом и приложением.
Улучшение производительности не гарантируется и не должно быть основной мотивацией. Время обнаружения и запуска может сократиться благодаря генерации исходного кода, однако время выполнения, запуск процесса, развертывание и оставшаяся часть Reflection могут определять общую продолжительность. Редакционный вывод здесь заключается в том, что основная ценность эксперимента — повышение соответствия тестирования процессу развертывания, даже если выигрыш в скорости ограничен. При этом подход можно отменить: если затраты на этот путь превысят уровень добавляемого им доверия, можно сократить его частоту, изменить выбранный проект или остановить эксперимент, не нарушая работу набора управляемых тестов.