Я хорошо знаю, что то, что я сейчас хочу сделать, в настоящее время невозможно, поэтому я ищу обходной путь.
Прежде всего, предположим, что это высокомодульная прикладная система на основе микросервиса. Каждый микросервис имеет свои собственные модульные тесты, которые выполняются в его конвейере сборки, результаты публикуются в DevOps Azure - на данный момент проблем нет.
Однако необходимо выполнить некоторые интеграционные ( почти сквозные) тесты (назовем это набором интеграционных тестов) в правильно развернутой системе приложений. Это делается в назначенной среде (назовем это средой тестирования интеграции). Набор тестов будет выполняться в нескольких различных сценариях, поэтому выходные данные должны отражать это (это просто означает, что если имеется 4 сценария, выходной файл результатов теста будет иметь 4 набора тестов).
Кроме того, должна существовать прямая видимая связь между выпусками системы приложений и результатами их испытаний.
Для этого существует конвейер выпуска, в котором первые три этапа: развертывание в DEV, развертывание в INT и запуск интеграционных тестов.
Естественно, задача PublishTestResults используется для представления хорошего обзора результатов интеграционных тестов. Приложение-организатор тестирования интеграции генерирует один XML / сценарий JUnit, и в конце тестирования они становятся доступными для конвейера.
С учетом вышесказанного возникает проблема: существует необходимость представлять определенную статистику о тестах, выполняемых в каждом сценарии / наборе (более интересные вещи, чем X / Y-тесты, выполненные за Z секунд).
Я знаю, что Jenkins CI, похоже, следует формату JUnit XML , описанному Дирком Джагдманном, а именно, что элемент <testsuite> может иметь элемент <system-out>, и это будет отображаться в визуализации набора тестов.
К сожалению (!), Azure DevOps Задача PublishTestResults читает только <system-out> под отдельными <testcase> элементами (ссылка выше показывает отображение формата результата). Ирония заключается в том, что наборы тестов и блейд-тесты отображаются в основном одинаково - у них обоих есть раздел Debug, в котором есть аккордеон с Error message, Stack Trace и т. Д. (Который не будет прочитан / заполнен для <testsuite> хотя).
То же самое относится к расширениям формата JUnit, которые позволяют ссылаться на дополнительные файлы вложений в XML.
Теперь, если бы это был конвейер сборки, я бы не позаботился и просто использовал бы задачу PublishBuildArtifacts, чтобы добавить несколько вложений .TXT (по одному на сценарий / набор) и сделать это. Однако эту задачу нельзя использовать в конвейере выпуска.
Мне нужны расширенные сводные данные / статистика для набора , и у меня не может быть их где-то в XML , который можно загрузить после выполнения нескольких, возможно, непонятных шагов . Это автоматически исключает их загрузку куда-то еще - если CI / CD находится в DevOps Azure, то все в нем должно оставаться там.
У меня есть полный контроль над генерацией XML результатов теста.