Вот, нашел неплохой инструмент для юнит-тестов. Очень понравился.
Интегрируется в "Студию", запускается на "раз-два", есть визард для создания тестовых классов,
поддерживает fixtures и прочие маленькие радости. Бесплатен. http://www.visualassert.com/unit-testing-framework/
Попробовал , действительно вещь! Особенно учитывая тот факт, что для C++ намного меньше таких програм чем для .Net. А вообще есть ли еще что-то подобное?
Здравствуйте, Аноним, Вы писали:
А>Попробовал , действительно вещь! Особенно учитывая тот факт, что для C++ намного меньше таких програм чем для .Net. А вообще есть ли еще что-то подобное?
Я пользовался Boost Unit Test Framework.
В принципе, если не брать во внимание отсутствие GUI, очень толковая штука.
Еще раньше пытался подружить CppUnit с VS2008, но ничего хорошего из этого не вышло.
Здравствуйте, okman, Вы писали:
O>Вот, нашел неплохой инструмент для юнит-тестов. Очень понравился. O>Интегрируется в "Студию", запускается на "раз-два", есть визард для создания тестовых классов, O>поддерживает fixtures и прочие маленькие радости. Бесплатен. O>http://www.visualassert.com/unit-testing-framework/
спасибо за наводку. на первый взгляд выглядит отлично — все срисовано с Unit Test Runner-а из решарпера,
но молодцы.
вопрос к тем кто пользуется visual assert:
*версии для скачивания почти годовой давности — это что — проект умер или есть платная постоянно развивающаяся версия?
*можно ли настроить возможность запуска тестов из модулей/бинариников расширения которых не .dll и не .exe?
Здравствуйте, okman, Вы писали:
O>Интегрируется в "Студию", запускается на "раз-два", есть визард для создания тестовых классов, O>поддерживает fixtures и прочие маленькие радости. Бесплатен. O>http://www.visualassert.com/unit-testing-framework/
Похоже, при всех плюсах, visual assert все-таки довольно сырой. На W7 x64 после установки родным инсталлятором он не заработал. (свои настройки не сохраняет, юнит тесты после прохода визардом не появляются в списке) Видимо, особенности 64 бит или W7. На stackoverflow тоже есть нарекания на него.
Менять систему из-за тест фреймворка нерационально, из всех оставшихся c++ unit test framework'ов с gui'ями нашелся только CPPUnit. Для VS2008 однако приходится брать его из SVN репозитория, стабильная версия с sourceforge'a не включает фикс для работы в VS2008. Может запускаться как MFC GUI application и выбирать тесты для прогона.
Здравствуйте, iAlexander, Вы писали:
A>Здравствуйте, okman, Вы писали:
O>>Интегрируется в "Студию", запускается на "раз-два", есть визард для создания тестовых классов, O>>поддерживает fixtures и прочие маленькие радости. Бесплатен. O>>http://www.visualassert.com/unit-testing-framework/
A>Похоже, при всех плюсах, visual assert все-таки довольно сырой. На W7 x64 после установки родным инсталлятором он не заработал. (свои настройки не сохраняет, юнит тесты после прохода визардом не появляются в списке) Видимо, особенности 64 бит или W7. На stackoverflow тоже есть нарекания на него. A>Менять систему из-за тест фреймворка нерационально, из всех оставшихся c++ unit test framework'ов с gui'ями нашелся только CPPUnit. Для VS2008 однако приходится брать его из SVN репозитория, стабильная версия с sourceforge'a не включает фикс для работы в VS2008. Может запускаться как MFC GUI application и выбирать тесты для прогона.
Видимо, лучше Boost Unit Testing Framework и Google Test ничего так и не появилось.
Вообще не понимаю ситуации. Кого не послушай, так у "них на работе" целые бригады только
тем и занимаются, что пишут и гоняют тесты. А когда начинаешь для себя что-то искать — глухо,
как будто эта отрасль программирования никем никогда не использовалась.
С CppUnit вообще больше не хочу связываться, ибо его разработка застыла где-то в середине
двухтысячных.
В свое время искал тестовый фреймворк для С++ со следующими (не считаю, что сильно
завышенными) требованиями:
— простой в использовании (чтобы не приходилось плодить лишние подклассы и fixtures);
— поддержка 32- и 64-разрядных систем;
— наличие вариантов по встраиванию в исходный проект;
— поддержка вывода в XML (у меня тесты гоняет билд-сервер, а все отчеты доступны только
через веб-панель, а XML легче перегнать в HTML с помощью XSLT, чем неформатированный текст).
Из тех фреймворков, что пробовал, Boost UTF оказался самым дружелюбным и подходящим.
P.S. GUI для систем юнит-тестирования теперь вообще не признаю.
Здравствуйте, okman, Вы писали:
O>- поддержка вывода в XML (у меня тесты гоняет билд-сервер, а все отчеты доступны только O>через веб-панель, а XML легче перегнать в HTML с помощью XSLT, чем неформатированный текст).
O>Из тех фреймворков, что пробовал, Boost UTF оказался самым дружелюбным и подходящим.
O>P.S. GUI для систем юнит-тестирования теперь вообще не признаю.
Когда все тесты проходят без ошибок — пусть они гоняются хоть в Африке
Когда отдельный тест выбрасывает ошибку, код нужно отлаживать. Для этого нужно запустить один только данный тест, ну а для этого в свою очередь желательно иметь GUI, чтобы а) не править тучу конфигов б) запускать в Visual Studio в режиме Debug.
Когда юнит-тестирование внедряется в полуготовый проект, отладка тестов/кода особенно актуальна.
А как вы справляетесь в Boost'овом фреймворке с выборочным запуском тестов и отладкой кода, который они тестируют?
Здравствуйте, iAlexander, Вы писали:
A>Здравствуйте, okman, Вы писали:
O>>- поддержка вывода в XML (у меня тесты гоняет билд-сервер, а все отчеты доступны только O>>через веб-панель, а XML легче перегнать в HTML с помощью XSLT, чем неформатированный текст).
O>>Из тех фреймворков, что пробовал, Boost UTF оказался самым дружелюбным и подходящим.
O>>P.S. GUI для систем юнит-тестирования теперь вообще не признаю.
A>Когда все тесты проходят без ошибок — пусть они гоняются хоть в Африке A>Когда отдельный тест выбрасывает ошибку, код нужно отлаживать. Для этого нужно запустить один только данный тест, ну а для этого в свою очередь желательно иметь GUI, чтобы а) не править тучу конфигов б) запускать в Visual Studio в режиме Debug. A>Когда юнит-тестирование внедряется в полуготовый проект, отладка тестов/кода особенно актуальна. A>А как вы справляетесь в Boost'овом фреймворке с выборочным запуском тестов и отладкой кода, который они тестируют?
Это вопрос возможностей Boost UTF или правильности процесса разработки ?
Если первое, то упомянутый фреймворк умеет выполнять только нужные тесты (см. Test Runner).
На второй отвечу так — у нас принят подход, при котором любой компонент
тщательнейшим образом тестируется еще до попадания в общую кодовую базу.
И тестирование на билд-сервере имеет, в каком-то смысле, формальный характер.
Нет, ну там бывает, конечно, что что-то падает, но достаточно редко, и это почти
всегда связано не с юнит-тестами, а с функциональными и другими "большими".
Так что в GUI потребности почти никогда не возникало. Ну а если какой-нибудь
мастер напишет графическую оболочку к Boost Unit Testing Framework, будет не
лишним, по меньшей мере...
A>>А как вы справляетесь в Boost'овом фреймворке с выборочным запуском тестов и отладкой кода, который они тестируют?
O>Это вопрос возможностей Boost UTF или правильности процесса разработки ?
Скорее всего так: вопрос удобства разработки новых тестов девелопером, либо (что в данном контексте то же самое) отладки некоторых отдельных старых тестов.
Если бы речь шла о Java/.Net, то там все сводится к выбору в окошке UnitTest'ов нужного теста из списка и его запуска прямо из IDE в режиме Debug.
А как это делается в случае применения Boost'ового фреймворка?
Здравствуйте, iAlexander, Вы писали:
A>>>А как вы справляетесь в Boost'овом фреймворке с выборочным запуском тестов и отладкой кода, который они тестируют?
O>>Это вопрос возможностей Boost UTF или правильности процесса разработки ? A>Скорее всего так: вопрос удобства разработки новых тестов девелопером, либо (что в данном контексте то же самое) отладки некоторых отдельных старых тестов. A>Если бы речь шла о Java/.Net, то там все сводится к выбору в окошке UnitTest'ов нужного теста из списка и его запуска прямо из IDE в режиме Debug. A>А как это делается в случае применения Boost'ового фреймворка?
Новые тесты создаются элементарно — в проект добавляется cpp-файл с кодом теста, а
все остальное выполняет архитектура в "лице" Visual Studio, Boost UTF и пары
самописных утилит для запуска и обработки результатов TestRunner-а.
TestRunner умеет делать прогон отдельных тестов, а вот когда надо запускать
многократно один и тот же (обычно в процессе разработки), тогда можно использовать
конфигурационный файл TestRunner-а — если он пустой, запускаются все тесты, а
иначе запускаются только те, что в нем прописаны. Сам файл помечается
специальным атрибутом SVN, так что разработчику не нужно беспокоиться о том,
что он вдруг забудет перед коммитом "вернуть все на место" — это будет
сделано SVN автоматически.
Да, я знаю, все это похоже на набор патчей и заплаток, но эта система
реально работает и используется уже примерно полгода безо всяких нареканий.
Кроме того, она чрезвычайно легко переносится в другое окружение.
Время от времени появляется какая-нибудь задача, которая не вписывается в
систему, и тогда система дорабатывается. Обычно это не вызывает проблем.
А других нормальных тестовых фреймворков, да еще с GUI, я пока не видел.
Если соберусь когда-нибудь, да будет время, напишу нормальный фронт-енд для Boost UTF.
Здравствуйте, okman, Вы писали:
O>TestRunner умеет делать прогон отдельных тестов, а вот когда надо запускать O>многократно один и тот же (обычно в процессе разработки), тогда можно использовать O>конфигурационный файл TestRunner-а
Т.о., если я правильно понял, запускается exe TestRunner (а при отладке он ставится Startup Project'ом), который на основе текстового конфига запускает выбранные тесты, результаты видимо складываются в файл отчетов, а из VS в режиме Debug можно отлаживать выбранный тест(ы).
Тогда CPPUnit мало чем отличается от этой схемы кроме красивой полоски прогрессбара, которую успешно можно показывать начальству. А значит в случае необходимости тесты можно будет перевести и на Boost UTF, раз они оба не интегрируются с IDE так, как делает это Visual Assert.
Здравствуйте, iAlexander, Вы писали:
A>Здравствуйте, okman, Вы писали:
O>>TestRunner умеет делать прогон отдельных тестов, а вот когда надо запускать O>>многократно один и тот же (обычно в процессе разработки), тогда можно использовать O>>конфигурационный файл TestRunner-а A>Т.о., если я правильно понял, запускается exe TestRunner (а при отладке он ставится Startup Project'ом), который на основе текстового конфига запускает выбранные тесты, результаты видимо складываются в файл отчетов, а из VS в режиме Debug можно отлаживать выбранный тест(ы). A>Тогда CPPUnit мало чем отличается от этой схемы кроме красивой полоски прогрессбара, которую успешно можно показывать начальству. А значит в случае необходимости тесты можно будет перевести и на Boost UTF, раз они оба не интегрируются с IDE так, как делает это Visual Assert.
CppUnit в практическом отношении отличается от этой схемы в первую очередь тем (с чисто
моей точки зрения), что его невозможно по-человечески взять и скомпилировать для
использования в Visual Studio 2008 — вываливаются ошибки компиляции, разбираться с
которыми нет абсолютно никакого желания. Я делал две попытки в разное время и ситуация
никак не изменилась. Не знаю, как дела обстоят сейчас, но это уже и не важно.