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

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

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

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

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

Источник

6 ответов

Решение

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

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

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

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

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

Источник

Я проверил плагин 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"

Источник

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

Источник

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

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

С уважением

Источник

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

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

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

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

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

Источник

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

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

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

Источник
Другие вопросы по тегам