CXX Test Framework для C++
Насколько эффективна инфраструктура тестирования CXX, учитывая, что вы пишете блок-тесты вокруг кода, который вы написали. Любая ошибка в коде может также быть преобразована в ошибку в коде модульного теста? Разве это не что-то вроде двух негативов, создающих позитив?
Кроме того, время и усилия, потраченные на CXX, по крайней мере равны, если не больше, чем усилия по написанию кода.
Нужны ваши мысли по этому поводу, так как я не поддерживаю использование этой структуры в моем проекте и ищу сильные стороны, чтобы противостоять этому.
С другой стороны, если вы думаете, что это полезно, пожалуйста, просветите меня:).
4 ответа
CXX не очень активен, и написание модульного теста обычно требует много усилий. Но когда приходит первый рефакторинг, вы очень благодарны за потраченные усилия.
Я использовал Boost.Test & CPPUNIT. Я бы предпочел немного Boost.Test, но да, вы должны писать свои собственные проекты, файлы и т. Д.
Если вы знаете инструмент для создания вашего скелета из вашего кода, я весь в ушах.:)
Я бы посоветовал вам попробовать Boost.Test и CPPUNIT. Если вы думаете, что есть лучшее, это даст вам хорошие возможности противостоять CXXUNIT, поскольку вы будете предлагать альтернативы.
Google предлагает фантастическую среду тестирования C++, которую я использовал... Я никогда не использовал никакую другую среду тестирования C++, и у меня был ограниченный опыт работы с Junit, и я смог поднять это очень быстро, так как документация хороша. Важно использовать хорошую платформу для тестирования, потому что тестирование слишком важно, чтобы от него отказываться из-за разочарования в этой среде. Вот ссылка:
http://code.google.com/p/googletest/
Надеюсь это поможет!
Я использую cxxtest. Регрессивное тестирование - это дорогостоящая задача, которую мы используем только для проверки наших программных библиотек, которые обеспечивают независимый от платформы уровень для наших приложений. Это делается для того, чтобы все изменения не влияли на стабильность кода, поскольку очень много приложений и проектов зависели от них.
Мы соединяем cxxtest с анализом покрытия, чтобы обеспечить достаточность покрытия тестами, а также с CruiseControl для его автоматизации.
Но мы не делаем это для приложений. Слишком много усилий.
Создать тестовое приложение так же сложно, как написать всю библиотеку. Я согласен, что вам нужно будет решить, стоит ли это того.
Я думаю, что Джоэлу тоже есть что сказать по этому поводу: http://www.joelonsoftware.com/items/2009/01/31.html
Я предпочитаю тестовые рамки только для заголовков, вот две из них: TUT и Catch. Я использовал TUT раньше в нескольких проектах, и недавно нашел Catch.
1) TUT - C++ Шаблон модульного тестового фреймворка
TUT - это небольшая и портативная среда модульного тестирования для C++.
- TUT очень переносим, независимо от того, какой компилятор или ОС вы используете.
- TUT состоит только из заголовочных файлов. Нет библиотеки, развертывание никогда не было проще.
- Пользовательский интерфейс репортера позволяет интегрировать TUT практически с любой IDE или инструментом в мире.
- Поддержка многопроцессного тестирования (ведется тестирование взаимоблокировок и тайм-аутов).
- TUT является бесплатным и распространяется по лицензии, подобной BSD.
- Тесты организованы в именованные тестовые группы.
- Регрессия (все тесты в приложении), выполнение одной группы или одного теста.
- Чистый C++, без макросов!
2) Catch - современный, C++ - собственный, только заголовочный, фреймворк для юнит-тестов, TDD и BDD
В чем подвох?
Catch обозначает C++ Automated Test Cases в заголовках и представляет собой многопарадигмированную среду автоматического тестирования для C++ и Objective-C (и, возможно, C). Он полностью реализован в виде набора заголовочных файлов, но для дополнительного удобства упакован в один заголовок.