Хадсон, C ++ и UnitTest ++

Question

Кто-нибудь использовал Hudson в качестве сервера непрерывной интеграции для проекта C ++, используя UnitTest ++ в качестве библиотеки тестирования?

Как именно вы это настроили?

Я знаю, что раньше было несколько вопросов о непрерывной интеграции, но я надеюсь, что этот вопрос имеет более узкий охват.

РЕДАКТИРОВАТЬ: Я немного уточнить, что я ищу. У меня уже есть набор для сбоя при неудачном тестировании модулей. Я ищу что-то вроде поддержки Хадсона JUnit. UnitTest ++ может создавать отчеты XML (см. здесь ). Так что, возможно, если кто-то знает, как перевести эти отчеты, чтобы они были совместимы с JUnit, Хадсон будет знать, как их съесть?

Answer 1

Мы активно занимаемся этим на моем рабочем месте.

В настоящее время мы используем проект программного обеспечения в свободном стиле для:

• Проверяйте наш репозиторий Subversion на обновления каждые 15 минут
• Вызовите пакетный файл Windows для очистки и построения файла решения.
  • Файлы проекта собирают и запускают модульные тесты как событие после сборки
  • Сбои модульного теста возвращаются тестом main(), поэтому обрабатываются как ошибки сборки

Я также протестировал конфигурацию, которая использует XmlTestReporter, включенный в UnitTest ++, для генерации выходных файлов. Плагин xUnit изначально поддерживает этот вывод наряду с любыми другими выходными данными, которые вы можете преобразовать, хотя мне пришлось изменить файл XSL, который прилагается к нему в версии 0.1.3, чтобы получить длительности, записанные в истории тестирования. 1020 *

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

Answer 2

Я проверил плагин xUnit , как предложил Патрик Джонмейер в принятом ответе. Для полноты, вот код драйвера:

#include <fstream>
#include "UnitTest++.h"
#include "XmlTestReporter.h"

int main( int argc, char *argc[] ) {
    std::ofstream f("file.xml");
    UnitTest::XmlTestReporter reporter(f);
    return UnitTest::RunAllTests(reporter, UnitTest::Test::GetTestList(), NULL, 0);
}

В конфигурации Hudson отметьте «Опубликовать отчет о результатах инструментов тестирования» и укажите "file.xml"

Answer 3

У Хадсона теперь есть плагин CppUnit , который может добиться цели.

Answer 4

Я использую Hudson с выходом CppUnit и xml. Xml преобразуется xslt в вывод JUnit, например. Сайт CppUnit предоставляет xslt, который преобразует выходные данные CppUnit в выходные данные JUnit. Я немного его взломал, чтобы узнать подробности:

• пространства имен как пакеты
• время исполнения

вы можете преобразовать свой вывод xml, чтобы получить следующее:

<?xml version="1.0" encoding="UTF-8"?>
<testsuite>
   <testcase name="my test name"
             classname="Package1.Package2.TestClass"
             time="0.25">
      <error type="error"/>
   </testcase>
   ....
</testsuite>

В случае успеха: просто удалите вложенный тег

С уважением

Answer 5

Задолго до того, как я начал использовать Hudson, я работал над проектом C ++, где мы использовали cpp-unit-lite и CruiseControl

Мы изменили Cpp-unit-lite для генерации JUnit, например файлов отчетов XML, а CruiseControl поднял файлы отчетов XML.

Вы можете сделать то же самое для UnitTest ++, и Хадсон подберет файлы отчетов.

Тем не менее, это похоже на большую работу. Взгляните на сюжетный плагин для Hudson. У вас может быть скрипт, который извлекает количество неудачных / успешных тестов из выходных данных UnitTest ++ и использует плагин plot для построения простого графика прохождения / неудачных тестов для каждой сборки.

Не так хорошо, как встроенный отчет о модульных тестах, но что-то, что вы можете быстро получить.

Answer 6

Мы использовали аналогичный подход в моем офисе, за исключением использования cxxtest вместо UnitTest ++, и сейчас мы находимся в процессе перехода на чрезвычайно превосходную (imho) среду gtest для google.

С cxxtest мы сделали что-то похожее на то, что предложил Патрик Дж. Это было в основном добавить шаг сборки, который запускал бы программу набора тестов через ant и приводил к сбою сборки, если какие-либо тесты провалились. Недостаток этого подхода заключается в том, что когда сборка завершается неудачно из-за результатов теста, вам нужно искать выход консоли, чтобы выяснить, что пошло не так. Также вы теряете изящные диаграммы, которые может сгенерировать Hudson, если ваша тестовая среда может выводить совместимый с junit XML.

Одним из мотивирующих факторов для перехода на gtest является то, что он генерирует junit XML, поэтому теоретически hudson может анализировать результаты теста и публиковать их более разумным способом. В любом случае, не похоже, что UnitTest ++ генерирует что-то подобное (пожалуйста, исправьте меня, если я ошибаюсь), так что это может быть спорным вопросом, но, по крайней мере, интеграция его в процесс сборки обеспечит запуск тестов во время строит.