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

StackOverflow https://stackoverflow.com/questions/411218

Вопрос

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

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

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

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

Это было полезно?

Решение

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

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

  • Проверяйте наш репозиторий 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, я работал над проектом 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++, и теперь мы находимся в процессе перехода на значительно превосходящую (по моему мнению) инфраструктуру gtest от Google.

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top