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

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

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

• Проверяйте наш репозиторий Subversion на наличие обновлений каждые 15 минут
• Call a windows batch file to clean and build a solution file
  • Project files build and run unit tests as a post-build event
  • Сбои модульного теста возвращаются тестом main(), поэтому рассматриваются как ошибки сборки.

Я также протестировал конфигурацию, которая использует XmlTestReporter, включенный в UnitTest ++, для создания выходных файлов. Плагин xUnit изначально поддерживает этот вывод вместе с любым другим выводом, который вы можете convert, хотя мне пришлось изменить 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"

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

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

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

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

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

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

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

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

С Уважением

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

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

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