Проблема заключается не в самом появлении красного билда, а в том, чтобы понять, вызвано ли оно новой регрессией, нестабильным тестом или аварийным завершением хоста тестов, из-за которого были удалены необходимые для расследования доказательства. В .NET Blog объясняется, как Microsoft.Testing.Platform, или MTP, может сделать отчеты о тестах более полезными для разработчиков, ревьюеров и инструментов непрерывной интеграции, вместо того чтобы просто показывать длинный список журналов.
Эти рекомендации предназначены для команд, использующих GitHub Actions или Azure DevOps и желающих, чтобы информация о сбоях поступала непосредственно в точку принятия решения внутри запроса на слияние. Платформа также позволяет создавать несколько форматов отчета за один запуск и предоставлять структурированные выходные данные, которые программы, информационные панели и инструменты разработки могут стабильно использовать.
Используйте историю сборок, чтобы различать регрессию и нестабильный сбой
Azure DevOps уже отображает доказательства тестов на вкладке Tests, но передача исторического окна в репортер добавляет контекст к каждому сбою. При использовании параметра --report-azdo-flaky-history 14 платформа запрашивает историю конвейера за 14 дней, а затем отличает тест, который периодически завершается сбоем, от теста без аналогичной истории.
Нестабильный тест может отображаться с меткой [flaky: failed 3/20 in last 14d], тогда как сбой без такой записи получает метку [REGRESSION]. Это помогает ревьюеру начать расследование с подходящего направления: сбой без истории требует немедленного внимания как потенциальная регрессия, тогда как повторяющийся сбой следует рассматривать с учетом его известной истории.
Если команда хочет изменить такое поведение непрерывной интеграции, существует параметр --report-azdo-demote-known-flaky, который преобразует известные нестабильные сбои в предупреждения, сохраняя регрессии ошибками. Однако источник подчеркивает, что решение должно быть явным: хотим ли мы использовать историю только для направления ревьюера или хотим, чтобы она автоматически меняла уровень серьезности сбоя? В конвейере testfx исторические комментарии использовались при сохранении всех состояний сбоя блокирующими сборку.
Та же история используется для обнаружения медленных тестов с помощью --report-azdo-slow-test-history. Параметр сравнивает каждый тест с его предыдущими показателями, используя настраиваемый множитель и минимальное количество запусков, чтобы один холодный запуск не приводил к неточному предупреждению.
Сохраняйте доказательства при аварийном завершении хоста тестов
Ранее результаты в формате TRX сериализовались в конце запуска, поэтому серьезная авария могла привести к потере всего отчета. Теперь результаты записываются на диск по мере их создания, а в сочетании с расширением дампа сбоев можно завершить частичный отчет при остановке хоста:
dotnet test --report-trx --crashdump
В результате создается корректный файл TRX, содержащий все завершенные тесты, а также список тестов, выполнявшихся в момент сбоя. Расширение также записывает файл с расширением .crash.sequence.log, в котором фиксируются начало и завершение каждого теста. Это помогает определить тест, который был запущен, но не завершился, даже при параллельном выполнении нескольких тестов.
Обработка вложений также охватывается этим механизмом. Дампы сбоев, комментарии остановки и файлы расширений тестов больше не игнорируются молча в .NET Framework, когда путь превышает ограничение Windows MAX_PATH. Если вложение невозможно скопировать, это отображается в консоли, а не остается указанным только внутри файла TRX. В результате незавершенный запуск явно отображается как незавершенный и не выглядит как зеленый отчет, скрывающий отсутствующие доказательства.
Выбирайте формат отчета в соответствии с его потребителем
Один запуск может активировать несколько форматов без отдельного шага преобразования. Формат TRX подходит для инструментов .NET, HTML — для непосредственного просмотра, а JUnit XML и CTRF JSON полезны для информационных панелей и кросс-технологической автоматизации. CTRF предоставляет общую схему JSON для объединения результатов .NET с результатами других языков.
Системы непрерывной интеграции читают форматы TRX и JUnit в представлениях результатов, тогда как HTML и CTRF отображаются как файлы, которые можно скачать или использовать в информационных панелях. В Azure DevOps параметр --report-azdo-upload-artifacts files позволяет автоматически загружать файлы с доказательствами результатов. Также следует задавать имена файлов с помощью параметра --report-<format>-filename и заполнителей вроде {asm} и {tfm}, чтобы результаты не конфликтовали в проектах, предназначенных для нескольких сред выполнения.
Сделайте выходные данные стабильными и пригодными для автоматизации
Параметр --list-tests json предоставляет документ с версией схемы, описывающий обнаруженные тесты и их исходные расположения. Это стабильная основа для выбора тестов, анализа влияния изменений и интеграции со средами разработки, вместо анализа текста консоли, который может меняться между версиями.
Выходные данные MTP адаптированы к средам агентов и языковых моделей: информационная полоса, символы ANSI и анимация прогресса скрываются, а по умолчанию stdout и stderr отображаются только для неудачных тестов. Поведение можно контролировать с помощью NO_COLOR и параметров --ansi и --progress.
Зафиксируйте политику отчетов и проверьте совместимость
Материал рекомендует опробовать MTP 2.3 или более новую версию в одном тестовом проекте, а затем включить --report-gh в GitHub Actions или --report-azdo в Azure DevOps. После выбора политики настройки сохраняются в файле testconfig.json внутри репозитория, чтобы локальные запуски и запуски CI создавали одинаковые отчеты. Также можно использовать Directory.Build.props для применения единых настроек ко всем тестовым проектам или использовать профиль AllMicrosoft для включения стабильного набора расширений, оставляя JUnit и CTRF необязательными.
Командам, не использующим MSTest.Sdk, следует проверить соответствие версий пакетов репортеров версии MTP, на которую ориентируется тестовый фреймворк. Поддержка MTP 2.x распространяется на MSTest.TestAdapter 4.0.0, NUnit3TestAdapter 6.0.1, TUnit 1.7.16, YoloDev.Expecto.TestSdk 0.16.0 и предварительные версии xunit.v3 4.0. Кроме того, решение не поддерживает смешивание проектов MTP и VSTest, поэтому участие в запуске MTP следует настраивать на уровне репозитория.
Параметрам истории Azure DevOps требуется токен SYSTEM_ACCESSTOKEN: $(System.AccessToken). Без него запуск продолжается, но исторические комментарии пропускаются. В существующих конвейерах задачи публикации результатов тестов и публикации файлов можно заменить соответствующими параметрами MTP, однако публикация покрытия кода не заменяется; поэтому необходимо сохранить PublishCodeCoverageResults@2. Также не следует одновременно включать прямую публикацию и PublishTestResults@2, поскольку это создает два отдельных запуска тестов для одной и той же сборки.