Hudson, С++ и UnitTest ++

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

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

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

EDIT: Я немного уточню, что я ищу. У меня уже есть набор сборки, который терпит неудачу, когда Unit-Tests терпят неудачу. Я ищу что-то вроде поддержки Hudson JUnit. UnitTest ++ может создавать отчеты XML (см. здесь). Итак, возможно, если кто-то знает, как перевести эти отчеты как совместимые с JUnit, Хадсон будет знать, как его съесть?

ОТВЕТЫ

Ответ 1

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

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

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

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

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

Ответ 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"

Ответ 3

У Hudson теперь есть плагин CppUnit, который может сделать трюк.

Ответ 4

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

Мы изменили Cpp-unit-lite, чтобы генерировать JUnit как файлы отчетов XML, а CruiseControl собрал файлы отчета XML.

Вы можете сделать то же самое для UnitTest ++, и Hudson возьмет файлы отчетов.

Однако это похоже на большую работу. Посмотрите плагин сюжета для Хадсона. Вы можете получить script количество тестов с ошибкой/прохождением из вывода UnitTest ++ и использовать плагин для построения простого графика тестов прохождения/сбоя на сборку.

Не так хорошо, как встроенный отчет unit test, но вы можете быстро работать.

Ответ 5

Я использую 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>

В случае успеха: просто удалите субтег

С уважением

Ответ 6

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

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

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