Пользователь
0,0
рейтинг
27 февраля 2013 в 00:00

Разработка → Модульное тестирование и непрерывная интеграция при помощи Jenkins для C++ проектов tutorial

Думаю, что все знают, что такое модульные тесты, все знают или, по крайней мере, слышали, что такое непрерывная интеграция, и многие программируют на C++. Но я столкнулся с тем, что в интернете не так много информации о том, как же это все объединить и заставить работать вместе. Эта статья является попыткой дать новичками пошаговую инструкцию, которая позволит сделать первый шаг в создании модульных тестов для C++ проектов и организовать покоммитный прогон модульных тестов при помощи CI сервера.
Update: План:
  1. Напишем HelloWorld
  2. Настроим сборку HelloWorld на Jenkins
  3. Напишем модульный тест для HelloWorld
  4. Настроим прогон модульных тестов на Jenkins

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



Предварительные требования



Для достижения поставленной задачи нам потребуется:
  • Доступ к системе версионного контроля (subversion, mercurial или git). В данной статье я использую subversion репозитарий на своем собственном сервере. Вы можете использовать, например, любой свободный репозиторий типа GitHub или bitbucket.
  • Сборочный сервер или сервер непрерывной интеграции (Continuous integration server). В данной статье используется Jenkins. Но есть и другие неплохие варианты. На данном сервере должна быть возможность сборки C++ проектов. Так же нужен плагин xUnit.
  • Какая нибудь среда разработки на Вашем десктопе. В данной статье я использую Netbeans 7.3 С++ редакция.
  • Компилятор C++. Я использую gcc.


Пара слов, почему именно Netbeans. Эта среда разработки единственная, которая включает и возможности по интеграции с системами версионного контроля и поддержку модульных тестов для C/C++ на уровне IDE. Это не означает, что другие IDE не могут быть использованы для создания модульных тестов, это означает, что в этой IDE начать разрабатывать модульные тесты может быть чуть проще, чем c другими IDE. То есть, проще для новичков.

Дабы меня не закидали помидорами поклонники Windows и Visual Studio, сразу оговорюсь, что Visual Studio в этом смысле, говорят, весьма хороша. Но я не пользуюсь Windows.

Создаем HelloWorld проект



  1. Опционально. Я рекомендую создать новый репозитарий, если у Вас есть такая возможность. Принцип «один проект — один репозитарий» это очень хороший принцип, на мой взгляд.
  2. Получите локальную копию репозитария, который Вы используете. Для subversion это checkout, для git и mercurial это clone.
  3. Создайте в репозитарии папку для проекта (это в том случае, если у Вас не отдельный репозитарий). В моем случае это папка 'unittests' в svn репозитарии.
  4. Запустите Netbeans:
    image
  5. Создайте новый проект: меню File -> New Project.
  6. Выберите «C/C++ Application» в качестве типа проекта
  7. image
  8. Укажите имя проекта (у меня — 'helloworld'), и местоположение проекта (Project Location), в которой он будет находиться (у меня на скриншоте это та самая папка, которую я получил с subversion сервера. В поле 'Project Folder' Вы получите полный путь, где будет храниться полученный проект. Остальные поля можно оставить без изменения.
    image
  9. Нажмите на кнопку 'Finish'.
  10. После этого будет создан проект с единственным файлом исходного текста.
    image
  11. Обратите внимание, что в списке файлов файл 'main.cpp' помечен зеленым цветом. Этим цветом помечаются новые файлы, которые отсутствуют в репозитарии.
  12. Выберите в главном меню: Team -> Subversion -> Show Changes (можно щелкнуть правой кнопкой мыши по этому файлу и в попап меню выбрать Subversion -> Show Changes, но в дальнейшем я буду писать вариант через главное меню). В нижней части экрана появился список измененных файлов (пока это только main.cpp).
    image
  13. Можете щелкнуть правой кнопкой мыши по этому файлу и посмотреть, например, diff. Хотя пока это не интересно, так как в репозитарии еще было пусто.
    image
  14. Закоммитим изменения. Выберите в дереве проекта корень и в главном меню: Team -> Subversion -> Commit. Как видим здесь Netbeans создаст в репозитарии папку 'helloworld' и в ней файл main.cpp. А также все файлы проекта. Здесь же можно (нужно) добавить комментарий к комиту.
    image
  15. Обратите внимание, что после коммита в списке файлов main.cpp стал черный. То есть, в этом файле нет изменений.
  16. Хорошо бы еще попробовать собрать и запустить полученный проект. Нажимаем кнопку Play (или главное меню Run -> Run Project, или просто F6). Если все нормально, то после сборки Вы увидите сообщение типа: «RUN FINISHED; exit value 0; real time: 0ms; user: 0ms; system: 0ms»
  17. Если этого не произошло, то скорее всего есть какая-то проблема с настройками переменной среды окружения PATH или нехватка библиотек. Смотрите внимательно на сообщения, которые Вы получаете.
  18. Добавим в главную функцию вывод сообщения типа:
    cout << "Hello World!" << endl;
    

  19. И еще добавим подключение заголовочного файла:
    #include <iostream>
    

  20. Запустим еще раз, F6.
  21. Обратите внимание, что добавленные строки выделяются зеленой подсветкой слева от строки, а модифицированный файл в списке файлов теперь синий. На самом деле современные IDE это очень неплохие клиенты к системам версионного контроля. Эсили Вы поизучаете возможности, которые доступны в меню Team, то, возможно, что для некоторых из систем версионного контроля Вы можете отказаться от использования сторонних клиентов версионного контроля.
  22. Теперь diff файлов выглядит веселее.
    image
  23. Закоммитим и это изменение.


Сборка с командной строки



Для того, чтобы делать автоматическую сборку нам нужен какой нибудь сборочный скрипт для сборки с командной строки. Хорошим вариантом будет 'makefile' (хотя я знаю людей, которые C++ проекты предпочитают собирать при помощи 'ant'). Если Вы хорошо знаете как его создать, то сделайте это и этот параграф дальше не читайте. А если Вы новичок, то нужно что-то придумать.

Создание makefile отдельная большая тема, которая в рамки данной статьи никак не вмещается. Поэтому, мы пойдем самым простым для нас путем. Netbeans свой проект хранит, фактически, в виде makefile (правда, еще и с кучкой дополнительных файлов). Мы будем использовать, в качестве makefile именно его.

Вообще говоря, вопрос о том, стоит ли в репозитарии хранить файлы проекта или нет это очень спорный вопрос. Я считаю, что нет. Но сборочный скрипт обязан быть в репозитари. Проект Netbeans в данном случае, это такой компромис. Так как, как я и сказал, файлы проекта Netbeans, фактически, являются сборочным скриптом. Не самым лучшим, но все же сборочным скриптом.

  1. Откройте терминал (cmd.exe или FAR для пользователей Windows).
  2. Перейдите в папку проекта ('/home/risik/work/unittests/helloworld' у меня).
  3. Выполните с командной строки команду 'make clean', а затем 'make'
  4. Если у Вас не было проблем при сборке проекта из Netbeans, то и здесь проблем возникнуть не должно.
  5. Именно эти файлы мы и закоммитили ранее вместе с файлами проекта. Но Вы, по каким то причинам этого не сделали, то самое время сделать это.
  6. Из Netbeans: правой кнопки мыши по проекту, и далее: Subversion -> Commit. Однако, кажется в Netbeans есть небольшая ошибка. Среди прочих файлов у меня в папке проекта есть файл с именем '.dep.inc', который нужен для корректной обработки зависимостей. Обойтись без него можно — сборка работает, но лучше его се же добавить вручную.
  7. Второй вариант — с командной строки или тем, что Вы обычно используете для работы с Вашей системой версионного контроля.


У меня получился такой список файлов:
корень проекта:
  • Makefile
  • .dep.inc

папка nbproject:
  • Makefile-Debug.mk
  • Makefile-Release.mk
  • Makefile-impl.mk
  • Makefile-variables.mk
  • Package-Debug.bash
  • Package-Release.bash
  • configurations.xml
  • project.xml

папка nbproject/private:
  • Makefile-variables.mk
  • configurations.xml
  • private.xml


Начальная настройка Jenkins



  1. Откройте Jenkins в Вашем браузере (у меня на скриншотах он находится по адресу 192.168.1.109:8080/jenkins).
  2. Создайте новую задачу (Jenkins — New Job)
  3. Укажите имя для задачи и выберите тип задачи «Build a free-style software project».
    image
  4. Задайте конфигурацию, аналогично тому, что приведено на скриншотах.
    image
    image
  5. Рассмотрим подробнее поля, которые следует модифицировать.
    — Название работы. У меня она называется просто — helloworld-cpp
    — В секции 'Source Code Management' укажите тип используемой системы версионного контроля. У меня это 'Subversion'.
    — Дополнительные поля различаются для разным систем версионного контроля, для SVN самым важным из них является URL репозитария.
    — Внимание: когда Вы будете задавать это урл, то скорее всего, Ваш Jenkins скажет что-то в духе «Не могу подключиться к репозитарию». В конце длинного красного трейс лога можно найти слова: '(Maybe you need to enter credential?)' и ссылку на ввод логина и пароля. Укажите свой логин и пароль на репозитарий, и Jenkins его запомнит. Другой вариант — указать логин и пароль прямо в урле. Или третий вариант — разместить аутентификационную информацию прямо в домашней папке пользователя, под которым работает Jenkins.
    — В секции 'Build Triggers' я указал SCM сборку. То есть, сборку по расписанию. '*/15 * * * *' означает сборку каждый 15 минут.
    — Примечание: вообще лучше бы вместо SCM использовать push сборку по триггеру от Вашей системы версионного контроля, но создание такой конфигурации выходит за рамки статьи.
    — В секции 'Build' добавим новый шаг сборки типа 'Execute Shell'. Если у Вас Jenkins работает на Windows и у Вас на этом сервере не установлен cygwin (а как Вы вообще живете, если это так?), то, возможно, будет лучше выбрать вариант 'Execute Windows Batch Command'.
  6. Нажимайте кнопку сохранения и давайте попытаемся собрать проект.
  7. У меня он упал. Проблема легко локализуется, если посмотреть 'Console Log':
    Started by user anonymous
    Building in workspace /var/lib/jenkins/jobs/helloworld-cpp/workspace
    Checking out a fresh workspace because there's no workspace at /var/lib/jenkins/jobs/helloworld-cpp/workspace
    Cleaning local Directory .
    Checking out https://sergeyborisov.com/svn/teach/kcup_unittests/helloworld at revision '2013-02-25T01:37:54.054 +0700'
    A         main.cpp
    A         nbproject
    A         nbproject/Makefile-Release.mk
    A         nbproject/Makefile-impl.mk
    A         nbproject/Package-Release.bash
    A         nbproject/project.xml
    A         nbproject/Makefile-Debug.mk
    A         nbproject/Makefile-variables.mk
    A         nbproject/configurations.xml
    A         nbproject/private
    A         nbproject/private/Makefile-variables.mk
    A         nbproject/private/configurations.xml
    A         nbproject/private/private.xml
    A         nbproject/Package-Debug.bash
    A         Makefile
     U        .
    At revision 132
    [workspace] $ /bin/sh -xe /tmp/hudson8376440745271858508.sh
    + make all
    /tmp/hudson8376440745271858508.sh: 2: /tmp/hudson8376440745271858508.sh: make: not found
    Build step 'Execute shell' marked build as failure
    Finished: FAILURE
    
    

  8. Ну здесь все просто. У меня сервере не оказалось команды 'make'.
  9. А после второй итерации я узнал, что у меня отсутствует g++. Ну это тоже лекго устранятся.
  10. Лишь на третий раз все оказалось удачно
    Started by user anonymous
    Building in workspace /var/lib/jenkins/jobs/helloworld-cpp/workspace
    Updating https://sergeyborisov.com/svn/teach/kcup_unittests/helloworld at revision '2013-02-25T01:42:03.200 +0700'
    At revision 132
    no change for https://sergeyborisov.com/svn/teach/kcup_unittests/helloworld since the previous build
    [workspace] $ /bin/sh -xe /tmp/hudson8326466894395366933.sh
    + make all
    for CONF in Debug Release ; \
    	do \
    	    "make" -f nbproject/Makefile-${CONF}.mk QMAKE= SUBPROJECTS= .build-conf; \
    	done
    make[1]: Entering directory `/var/lib/jenkins/jobs/helloworld-cpp/workspace'
    "make"  -f nbproject/Makefile-Debug.mk dist/Debug/GNU-Linux-x86/helloworld
    make[2]: Entering directory `/var/lib/jenkins/jobs/helloworld-cpp/workspace'
    mkdir -p build/Debug/GNU-Linux-x86
    rm -f build/Debug/GNU-Linux-x86/main.o.d
    g++    -c -g -MMD -MP -MF build/Debug/GNU-Linux-x86/main.o.d -o build/Debug/GNU-Linux-x86/main.o main.cpp
    mkdir -p dist/Debug/GNU-Linux-x86
    g++     -o dist/Debug/GNU-Linux-x86/helloworld build/Debug/GNU-Linux-x86/main.o 
    make[2]: Leaving directory `/var/lib/jenkins/jobs/helloworld-cpp/workspace'
    make[1]: Leaving directory `/var/lib/jenkins/jobs/helloworld-cpp/workspace'
    make[1]: Entering directory `/var/lib/jenkins/jobs/helloworld-cpp/workspace'
    "make"  -f nbproject/Makefile-Release.mk dist/Release/GNU-Linux-x86/helloworld
    make[2]: Entering directory `/var/lib/jenkins/jobs/helloworld-cpp/workspace'
    mkdir -p build/Release/GNU-Linux-x86
    rm -f build/Release/GNU-Linux-x86/main.o.d
    g++    -c -O2 -MMD -MP -MF build/Release/GNU-Linux-x86/main.o.d -o build/Release/GNU-Linux-x86/main.o main.cpp
    mkdir -p dist/Release/GNU-Linux-x86
    g++     -o dist/Release/GNU-Linux-x86/helloworld build/Release/GNU-Linux-x86/main.o 
    make[2]: Leaving directory `/var/lib/jenkins/jobs/helloworld-cpp/workspace'
    make[1]: Leaving directory `/var/lib/jenkins/jobs/helloworld-cpp/workspace'
    Finished: SUCCESS
    



Создание тестов в Netbeans


Пока оставим Jenkins в покое и вернемся к Netbeans. Для начала немного модифицируем наш проект. Чтобы в нем было хоть что-то, что можно тестировать, пусть строку приветствия формирует отдельный класс.

  1. Щелкните правой кнопкой мыши на 'Source Files' и из контекстного меню выберите пункт New -> C++ Class.
  2. В диалоге создания класса задайте имя нового класса, например, Helloer (уж простите меня за это название, но я не смог придумать как это назвать). Вообще правильно было бы здесь задать папку для нового файла. Ну хотя бы 'src'. Но я поленился.
    image
  3. В списке файлов появится пара файлов — Helloer.cpp и Helloer.h. В Netbeans они создаются в одной папке, а в других IDE они могут создаваться в двух раздельных папках, например, 'src' и 'include'.
  4. Как Вы можете заметить конструктор без параметров, конструктор копирования и виртуальный деструктор создаются автоматически.
  5. Сперва закоммитим то, что было сгененировано, а потом добавим то, что нам надо. image image image
  6. То есть, я добавил к классу Helloer конструктор со строкой, в качестве параметра, в которой будет указано кого именно будем приветствовать. А также добавил метод получения сообщения с приветствием.
  7. Закомитим изменения. Обратите внимание, что модифицировались также и файлы проекта, их тоже надо закоммитить.
  8. Откройте Helloer.h, щелкните правой кнопкой мыши внутри файла и выберите пункт Create Test -> Create CppUnit Test.
  9. В появившемся диалоге выберите элементы, которые будете тестировать. Я выбрал только метод message. image
  10. На следующем диалоге укажите имя теста. Кстати, если Netbeans не нашел нужной библиотеки (cppunit) он Вам об этом скажет здесь. У меня это пакет libcppunit-dev.
    image
  11. Вот что у меня получилось после генерации тестов. image
  12. В структуре проекта появилась ветка HelloWorldTests — именно это название я дал всей группе тестов в диалоге конфигурации теста. А в ней модуль прогона тестов данной группы (Runner), который у меня называется 'HelloWorldTestRunner.cpp' и пока единственный класс теста — HelloerTest (.cpp + .h).
  13. Попробуем запустить. Меню Run -> Test Project. иии… Я получил фэйл — модульные тесты не собрались. Так как не нашлось заголовочного файла 'Helloer.h'. Ну здесь просто — надо добавить путь к файлу. Для этого вызовите контекстное меню на группе тестов HelloWorldTests и выберите пункт Properties. Вы увидите диалог свойств папки проекта. image
  14. В этом диалоге в разделе 'C++ Compiler' найдите пункт 'Include Directories' и нажмиете кнопку '...' справа.
  15. В появившемся диалоге 'Include Directories' нажмите кнопку 'Add' image
  16. И наконец выберите папку, где находится Ваш заголовочный файл. Поскольку этот файл является частью прроекта, то хранить путь к файлу нужно в относительном виде, что и указано в правой части диалога. Поскольку я ранее поленился создавать даже папку 'src' когда создавал класс Helloer, то у меня этой папкой будет папка проекта. То есть, папка '.'. image
  17. Закрываем диалог свойств и пытаемся снова запустить модульный тест.
  18. На этот раз он собрался, запустился, но упал, на Assertion.image
  19. Впрочем, я сразу закоммитил, все что сгенерировалось. А вот теперь поправлю тест:
    image
  20. И изменения также закоммичу. Обратите внимание, что коммитить нужно не только исходные тексты, но и файлы проекта.
  21. Откройте файл 'HelloWorldTestRunner.cpp' если присмотреться, то его структура проста и понятна:
    — Подготавливаем прогон тестов.
    — Прогоняем их.
    — Печатаем результат.
  22. Netbeans сгенерировал печать результата в 'compiler compatible' формате. Это очень удобный формат для работы в Netbeans, но неудобный формат для Jenkins. Поэтому, я добавлю еще и печать в XML формате:
    ofstream xmlFileOut("cpptestresults.xml");
    XmlOutputter xmlOut(&result, xmlFileOut);
    xmlOut.write();
    
  23. Естественно нужно включить необходимые заголовные файлы:
    #include <cppunit/XmlOtputter.h>
    #include <ostream>
    
  24. Примечание: печать в XML формате, не вместо текстового, а вместе с текстовым.
  25. Имя файла («cpptestresults.xml» у меня) и путь к нему можно было выбрать другой. Но главное, что бы Вы знали какой. Эта информация нам скоро понадобится.


Настраиваем прогон автотестов в Jenkins


  1. Открыл браузер с Jenkins и вижу, что он уже сделал несколько сборок. Я ведь указал ему SCM сборку каждые 15 минут. А следовательно, если при очередной проверке, которая осуществляется каждые 15 минут, как нетрудно догадаться, были новые коммиты в репозитарий, то Jenkins собирал проект. Ну а поскольку я писал это все неторопливо, то поводы для пары прогонов у него нашлось :)
  2. Здесь есть важный нюанс. Если системное время сервера с Вашим репозитарием и системное время сервера с Jenkins расходятся, то можно получить очень странные эффекты. Например, Jenkins откажется признавать, что возможные модификации исходного текста в будущем. Поэтому настоятельно рекомендую настроить на всех серверах синхронизацию времени и лучше всего по какому-то общему серверу ntp. Да и Ваш десктоп хорошо бы сихронизировать аналогичным образом.
  3. Добавляем к джобе «Post build action», например так:
    image
  4. Пробуем собрать. и вуаля! Все собрано и тест пройден! И у Вас в билде появилась информация о пройденных тестах:
    image
  5. А после того, как соберет еще раз в джобе появится график. Ну пока он у меня такой:
    image
  6. Зато в 'Latest Tests Results' можно увидеть более подробную информацию о всех пройденных и провалившихся тестах (пока единственном):
    image
  7. Не смущайтесь, что в таблице общего списка тестов Вы видите (root). Jenkins заточен под Java. И здесь должны были быть имена пакетов.
  8. Давайте сделаем еще один тест. При этом, будем иметь в виду сразу небольшую модификацию функциональности: Если приветствовать некого (строка 'who' не задана), то и не надо говорить никаких приветов.
  9. То есть, мы должны добавить следующие строки к заголовочному файлу:
    image
  10. и такой метод к .cpp файлу:
    void HelloerTest::testMessageNobody() {
        Helloer helloer;
        string result = helloer.message();
        if (true /*check result*/) {
            CPPUNIT_ASSERT(result == "");
        }
    }
    
    
  11. коммитим. И теперь или ждем очередного запуска сборки по SCM или запускаем сборку вручную.
  12. Теперь мы видим, что у нас есть упавший тест!
    image
  13. Правда, сборка все равно помечена как успешная. Вернемся к этому вопросу чуть позже.
  14. Зато тренд стал симпатичнее:
    image
  15. Пофиксим образовавшийся test fail:
    string Helloer::message() const
    {
        if (who.length() == 0)
            return "";
        return (string)"Hello " + who;
    }
    

  16. И снова прогоним тесты в IDE. Теперь здесь все ОК. Закоммитим, соберем на стороне Jenkins и видим что там тоже теперь все хорошо (у меня успела пройти сборка со все еще поломанным тестом).
    image
  17. Несколько слов о статусе сборки. Jenkins позволяет настроить формирование статуса довольно гибко. Эту конфигурацию можно увидеть в настройке шага xUnit в джобе — пукты 'Failed Tests' и 'Skipped Tests'. Как будет лучше конкретно для Вас — я не знаю. Но я считаю, что каждый новый упавший тест должен приводить к поломке сборки, то есть, сборка должна помечаться, как красная. А вот те тесты, которые были поломаны ранее, должны приводить к «желтому статусу». Поэкспериментируйте!

Ну вот и все! Если все таки дошли до сюда по всем шагам, а не просто пролистнули на конец страницы, то Вы сделали первый шаг в автоматизации прогона модульных тестов в Вашем C++ проекте. И первый шаг к TDD. Удачи!

Ссылки



Лицензия


Creative Commons License

Статья "Модульное тестирование и непрерывная интеграция при помощи Jenkins для C++ проектов" by Sergey Borisov (AKA risik) is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
Сергей Борисов @risik
карма
25,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (11)

  • +2
    Вы уверены, что людям, которым стоит начать работать по CI-методологии, нужно по пунктам расписывать, куда кликнуть, чтобы сделать HelloWorld-проект?
    • +3
      Я уверен, что начинать учиться писать модульные тесты нужно как можно раньше. Лучше сразу после того, как напишут isLeap. А если уж начали писать модульные тесты, то настоятельно рекомендуется и организовать CI. А если взялись за CI, то нужна автоматизация сборки. А создание вручную makefile процесс трудоемкий (я вот не напишу). А значит надо использовать какую-то IDE, которая сможет подходящий makefile сгенерировать. Такая нашлась одна — Netbeans. А вдруг раньше человек пользовался исключительно Anjuta, vim или Turbo C 2.0? :) Значит надо и базовые сведения о Netbeans.
      Может быть создание HelloWorld проекта и не нужно бы расписывать пошагово и с картинками, но раз уж я взялся описать по шагам все, то и это тоже.
      • 0
        Вообще CI никак не связан с модульными тестами, это вы сами себе придумали что «связано». Тот же Jenkins очень хорош помимо сборки самой, для именно _постоянной_ сборки, когда работа над проектом происходит распределенно в несколько групп разработчиков, к тому же у самого Jenkins есть куча плагинов (я его для с php использую). Да и сам Jenkins мало знать на уровне «кликов», нужно нормально почитать мануал и примеры Ant, и того какие таски уже есть, а то сделают сборку тупо из вызовов команд из шела :S
  • +1
    А я побаивался подбираться к этому зверю. Теперь пойду сервер настраивать.
  • 0
    Эх, текста много, а полезного для себя не нашел :(
    • 0
      А что ожидали найти?
      • 0
        Ну на пример, какие выхлопы каких тестовых фраемворков понимает Jenkins. Может быть какие то особенности в эксплуатации. У самого просто еще руки до этого не дошли (а может и не дойдут), а увидеть «как у других» и «что можно» хотелось бы.
        • +1
          > Ну на пример, какие выхлопы каких тестовых фраемворков понимает Jenkins.
          Легко отвечу на этот вопрос. Jenkins понимает только JUnit. А вот плагин xUnit, который я здесь использую, понимает:
          * JUnit itself
          * AUnit
          * MSTest (imported from MSTest Plugin)
          * NUnit (imported form NUnit Plugin)
          * UnitTest++
          * Boost Test Library
          * PHPUnit
          * Free Pascal Unit
          * CppUnit
          * MbUnit

          Это можно увидеть, когда Вы в первый раз конфигурируете сборку с использованием xUnit.

          А также есть расширения xUnit с поддержкой дополнительных форматов:
          * Gallio (Gallio plugin)
          * Parasoft C++Test tool(Cpptest Plugin)
          * JSUnit (JSUnit Plugin)
          * JBehave

          > Может быть какие то особенности в эксплуатации.
          Поскольку все таки это тьюториал здесь нет информации про то, что может, чего не может. Это немного не тот формат. Здесь есть информация ровно о том, как заставить его прогонять C++ модульные тесты.

          Ну а что он (Jenkins) может могу сказать с изрядной долей уверенности: ВСЕ! Просто большая часть функциональности вынесена в плагины. Посмотрите список плагинов.

          Как Вам, например, такой «экзотический» плагин:
          AWS Cloudformation Plugin — A plugin that allows for the creation of cloud formation stacks before running the build and the deletion of them after the build is completed.

          Да, Jenkins намного больше, чем просто сервер для прогона модульных тестов, в котором качестве я его использую в этом тьюториале. Но я и не пытался рассказать про все возможные кейсы его использования. Ровно про один. С которого можно начать С++ разработчику. А про остальные кейзы можно прочитать другие статьи. Статей по Jenkins на хабре много.
          • 0
            Подхватывает ли xUnit выхлоп BoostTest в консоль? Или нужно в файл?
            Пробовали GTest подключать?
            • 0
              Для xUnit нужен файл. Консоль подхватывать не умеет.
              BoostTest и GTest не пользовал, подробности рассказать не могу.
  • 0
    Лучше перенесите все изображения на habrastorage.org. Так как-то спокойней. А то откроешь статью, эдак, годика через 2, а у нее ни одной картинки нет. Считайте это заботой о будущих поколениях.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.