Phpunit: Поддержка нового стандарта для отчетов о результатах тестирования в формате XML.

XSD-файл JUnit5, указанный в # 2964, не принадлежит junit. Это тестовый ресурс, полученный из плагина jenkins xunit.

много лет назад мы нашли что-то вроде JUnit v10:
https://github.com/FriendsOfPHP/PHP-CS-Fixer/blob/2.12/doc/junit-10.xsd
Я считаю, что это было найдено в репозиториях Travis или где-то в этом роде

(да, официальной xsd пока нет, к сожалению)

Кроме того, после изменения названия проблемы вас может заинтересовать стиль проверки (не волнуйтесь, это не только стиль, но и любой инструмент для создания отчетов), который также широко используется в различных исполнителях CI:
https://github.com/FriendsOfPHP/PHP-CS-Fixer/blob/2.12/doc/checkstyle.xsd

Я надеюсь, что эта статья находится в нужном месте или подходит для этой темы. У меня возникли проблемы с использованием тестового вывода PHPUnit с системами, поддерживающими JUnit. Правильная поддержка JUnit была бы идеальной (по крайней мере, в рамках моей личной реализации), поскольку я видел JUnit как широко распространенный формат тестирования.

Правильная поддержка JUnit была бы идеальной

проблема в том, что никто не знает, как будет выглядеть надлежащая поддержка, поскольку нет официальной схемы данных для формата JUnit.

Правильная поддержка JUnit была бы идеальной

проблема в том, что никто не знает, как будет выглядеть надлежащая поддержка, поскольку нет официальной схемы данных для формата JUnit.

да и нет.
Библиотека JUnit java не определяет официальную схему для отчета XML. Вы можете выбрать одну из наиболее поддерживаемых схем ( maven surefire или

@keradus Простите меня, я определенно не эксперт в этом

JUnit 5 действительно поставляется с XSD:

https://github.com/junit-team/junit5/blob/master/platform-tests/src/test/resources/jenkins-junit.xsd

Похоже, это соответствует большинству сторонних XSD, которые мне удалось найти.

Вложенные testsuite элементы? Я удивлен, что это работает - их испускает что-нибудь, кроме PHPUnit?

(Какое-то безумие, как весь мир ОС использует JUnit XML в качестве стандарта де-факто, хотя буквально никто, кажется, не знает точно, с чем они якобы согласны - и мы все просто соглашаемся с этим ...)

Похоже, это соответствует большинству сторонних XSD, которые мне удалось найти.

Прекрасно, это звучит как хорошо описанный стандарт, подходящий для структуры тестирования. 😨
Реорганизация подсистемы событий и ведения журнала - одна из моих жевательных игрушек, и я добавил ссылку на JUnit 5 в свой список для чтения. Спасибо!

JUnit 5 действительно поставляется с XSD:

https://github.com/junit-team/junit5/blob/master/platform-tests/src/test/resources/jenkins-junit.xsd

Похоже, это соответствует большинству сторонних XSD, которые мне удалось найти.

Вложенные testsuite элементы? Я удивлен, что это работает - их испускает что-нибудь, кроме PHPUnit?

(Какое-то безумие, как весь мир ОС использует JUnit XML в качестве стандарта де-факто, хотя буквально никто, кажется, не знает точно, с чем они якобы согласны - и мы все просто соглашаемся с этим ...)

JUnit не поставляется с XSD. Этот XSD был скопирован для целей тестирования (проект платформенных тестов) плагином xunit (прочтите заголовок XSD). Этот файл был создан Грегори Буассино, оригинальным автором плагина jenkins xunit, который представляет собой своего рода путаницу всех обнаруженных случаев.

JUnit не поставляется с XSD

Ну, это часть набора тестов - так что, на мой взгляд, это часть спецификации.

Независимо от того, где он возник, это спецификация, которой придерживается сама кодовая база JUnit.

Или не?

Прежде чем распределять усилия, меня больше всего беспокоит: стабилен ли стандарт (XSD или нет), по крайней мере, на данный момент? Я счастлив реализовать его в PHPUnit, если так.

Ну, это часть набора тестов - так что, на мой взгляд, это часть спецификации.

Я бы согласился, если и только если XSD был включен для этой цели. Многие наборы тестов также включают тесты для сценариев, которые невозможно откатить, потому что сообщество разработчиков приняло еще одну «вечную бета-версию».

В собственной коллекции PHPUnit есть несколько средств защиты от старого поведения регистратора, что, откровенно говоря, не очень хорошо.

Ну, это часть набора тестов - так что, на мой взгляд, это часть спецификации.

Независимо от того, где он возник, это спецификация, которой придерживается сама кодовая база JUnit.

Или не?

Чтобы считаться специфическим, это должно быть объяснено в документации. Поскольку вы нашли тестовый ресурс, это не означает, что это официальная документация схемы. Имя файла jenkins -junit.xsd должно быть еще одним сигналом, не имеющим ничего общего с официальной схемой JUnit. Вы можете спросить их, является ли это официальной схемой для JUnit (я бы запомнил, что до JUnit4 библиотека не создает отчетов в каком-либо формате JSON, XML или другом)

Да, я не согласен, это явно не официальная схема, но ... ее нет.

Похоже, это самое близкое, что можно найти в их исходном репозитории или где-либо еще.

но ... его нет.

Дело в том, что JUnit - это просто библиотека для запуска тестов. Отчет не создается, поэтому нет причин для определения какого-либо стандарта. Кто использует JUnit движок и чем создает отчет, чем он может определять стандарт (который также может быть в другом формате, таком как JSON). На данный момент широко используются два исторических исполнителя: Maven и Ant. Оба они определили собственную схему для XML-отчета, и они полностью отличаются друг от друга. Это причина этой проблемы, определите стандарт PHPUnit (без каких-либо ограничений JUnit) в соответствии с потребностями PHP. Но до сих пор я не видел никакого движения.

Возможно, нам стоит создать собственный формат ведения журнала для PHPUnit. (Да, я знаю, https://xkcd.com/927/.)

В некоторой степени это уже существует, благодаря @arneblankerts , с лог- --coverage-xml . Генератор для этого нужно будет реорганизовать (и переместить, по крайней мере, частично, из php-code-покрытия в сам PHPUnit), чтобы только необязательно включать данные о покрытии кода.

Или мы ждем и надеемся, что https://github.com/ota4j-team/opentest4j/issues/9#issuecomment -382630222 приведет к чему-то, что мы сможем принять.

Генератор для этого нужно будет реорганизовать (и переместить, по крайней мере, частично, из php-code-покрытия в сам PHPUnit), чтобы только необязательно включать данные о покрытии кода.

Что произойдет с теми, кто использует php-code-cover независимо от php-unit?

Спасибо за то, что подняли этот вопрос, @ mindplay-dk. Это необходимо учитывать.

много лет назад мы нашли что-то вроде JUnit v10:
https://github.com/FriendsOfPHP/PHP-CS-Fixer/blob/2.12/doc/junit-10.xsd
Я считаю, что это было найдено в репозиториях Travis или где-то в этом роде

(да, официальной xsd пока нет, к сожалению)

Кроме того, после изменения названия проблемы вас может заинтересовать стиль проверки (не волнуйтесь, это не только стиль, но и любой инструмент для создания отчетов), который также широко используется в различных исполнителях CI:
https://github.com/FriendsOfPHP/PHP-CS-Fixer/blob/2.12/doc/checkstyle.xsd

Было бы здорово иметь поддержку checkstyle, потому что с ней мы также легко получаем аннотации проверок github через общий скрипт, который уже совместим с phpstan, psalm и php-cs-fixer (и любым другим инструментом, способным генерировать отчет в формате checkstyle)

https://github.com/staabm/annotate-pull-request-from-checkstyle/

@sebastianbergmann, согласны ли вы, чтобы PR добавлял отчеты в формате checkstyle xml?

как вы можете видеть из https://github.com/FriendsOfPHP/PHP-CS-Fixer/blob/2.16/src/Report/CheckstyleReporter.php#L35, реализация не будет сложной

Нет. Я не верю, что Checkstyle XML хорошо подходит для результатов тестирования.

вы видели результаты проверки api-принтера https://github.com/mheap/phpunit-github-actions-printer ?

мы могли бы легко поддерживать эту функцию, когда отчет создавался бы в формате checkstyle (с универсальным checkstyle в конвертер аннотаций github, например https://github.com/staabm/annotate-pull-request-from-checkstyle)

Заменено # 4321.