Прошу поделиться опытом настройки модульных тестов в C++?
Сейчас делаю так:
Используя MSVS 2012 создан проект с Boost.Test написанные модульные тесты включены в него. Когда хочу протестировать, то компилирую этот проект и запускаю получившийся exe-файл с параметрами --report_log=short.
Хочется получить более быстрый фидбек от юнит-тестов. Пока приходит в голову только создание новой конфигурации в основном проекте. Назвать эту конфигурацию UnitTests.
Хотел бы послушать других ребят, как они используют и как у них поставлен процесс использования юнит-тестов?
1) VS 2012 Unit tests
2) создано несколько плейлистов тестов, которые запускаются в ручную или при билде
3) обычно основной плейлист тестов выполняется при билде
посмотрите вот эти два видео с более подробным рассказом
для Boost.Test нужен враппер, такие же как сделаны для nUnit и xUnit, но можно и без Boost.Test, встроенный С++ Unit test framework вполне себе можно использоваь.
Пока вижу, что самое дешевое решение это новая конфигурация. От TestExplorer как я понимаю, я получу только разноцветные прошел\упал. Ну и playlist, но этого же можно достигнуть и в случае использовании конфигурации, где я должен в ручную исключать юнит-тесты из проекта
Ну как бы GoogleTest как бы его не хвалили менее удобен чем Boost.Test. Все конечно сугубо индивидуально, но поюзав и то и то выбор был сделан не в пользу gtest
Ну ведь не спроста gtest выбрали! Значит приключился какой-нибудь случай при котором он справился лучше. Вот и опишите, что не хватило в одном и достаточно было в другом! ;)
Ну главная причина - на билдсервере формат отчета гуглотестов поддерживался, сходу вышло запилить :) А так все как у всех - есть солюшн, внем куча проектов либ, и несколько проектов екзешников с минимальным функционалом, юниттесты пишутся для классов из либ. Один из экзешников - запускает юниттесты.
Т.е. у Вас запуск юнит тестов отдельным приложением так? Если да, то это ничем не отличается от того что я сейчас использую. Но это мне уже не подходит. Когда работа кипит, так и хочется сказать «Вот ща вот это еще допишу, и протестю», а все потому что переключение на тестовое приложение не достаточно быстро, чтобы эту операцию не откладывать. Грубо говоря, переключение на «тестирование» при использовании метода отдельного приложения, это своего рода смена деятельности мозга, а это хочется избежать ибо теряется азарт при решении основной задачи
Как я уже сказал, ничто не мешает запускать тесты каждый билд. Да, формально это будет одно приложение, но при фэйле теста можно сделать фэйл билда — то есть, если что-то сломалось, то проект не соберётся.
Так. Вернемся к условиям моего вопроса. Мой вопрос связан с юнит-тестами. Их ключевая роль частота запуска, а чтобы их хотелось чаще запускать они должны быстро работать и «быть под рукой». Мои юнит-тесты достаточно быстры, но они «не под рукой». Потому что переключить себя на компиляцию и запуск приложения с юнит-тестами это «далековато» как-то! Они должны быть «ближе» ;) Мне как раз и хочется организовать работу с юнит-тесами так, чтобы они были «очень близко» и чтобы у меня не возникало желания запустить их после достаточно большого кол-ва правок кода. А если фоновый режим, то это можно будет сделать только применяя CLang, а остальные мне кажутся монстроподобными динозаврами, а переход на CLang не готов, т.к. под виндами не очень-то он хорошо поддерживается )
В приведённом мною примере для сборки тестов используются уже имеющиеся объектники, т.о., из всей сборки работает лишь линковка.
Если же требуется иметь лишь один исполняемый файл, в CxxTest можно генерацию .cpp для теста вставить в начало сборки и добавлять полученный .cpp к основной программе, при этом задавать свою функцию main для него. И эту функцию уже вызывать из основной программы.
По сути, CxxTest — это генератор исходного кода программы теста, а уж с исходником можно делать что угодно.
Простой
Средний
