QtTest + gcov |
Здравствуйте, гость ( Вход | Регистрация )
QtTest + gcov |
Rocky |
6.5.2011, 17:05
Сообщение
#1
|
Старейший участник Группа: Участник Сообщений: 530 Регистрация: 22.12.2008 Из: Санкт-Петербург Пользователь №: 463 Спасибо сказали: 22 раз(а) Репутация: 7 |
Всем привет! Давно не было меня тут. Проект был на работе на чистом С, так что Qt пришлось отложить.. А щас время появилось свободное, решил поразбираться с модулем QtTest.
1. Вроде так все понятно, кроме одного. Нигде не написано, как именно интегрировать юнит-тестирование в проект. Нужно создавать отдельный проект, и к нему подключать само тестируемое приложение? А как подключать? Если тестируемое приложение - библиотека, то ок, проблем нет. А если исполняемый файл (exe)? 2. Есть такая утилитка gcov (наверняка слышали/знаете что такое), с помощью которой можно померить покрытие кода тестами. Чтобы заработала она, нужно в проекте прописать
Это много где написано что так, только мне неясно в каком именно проекте это нужно делать? В проекте-тестировщике или в тестируемом? Или в обоих? Заранее спасибо если кто что подскажет) |
|
|
Rocky |
10.5.2011, 12:51
Сообщение
#2
|
Старейший участник Группа: Участник Сообщений: 530 Регистрация: 22.12.2008 Из: Санкт-Петербург Пользователь №: 463 Спасибо сказали: 22 раз(а) Репутация: 7 |
Ну вот... Неужели никто не использовал QtTest при разработке?(
|
|
|
Rocky |
18.5.2011, 8:57
Сообщение
#3
|
Старейший участник Группа: Участник Сообщений: 530 Регистрация: 22.12.2008 Из: Санкт-Петербург Пользователь №: 463 Спасибо сказали: 22 раз(а) Репутация: 7 |
Нашел время чтобы отписать. Разобрался. Разрабатывал в линухах (в винде видимо будет то же самое, ну может с небольшими изменениями).
Вариант 1. 1. Создаем обычный проект (app). В pro-файл в SOURCES и HEADERS добавляем те файлы с функами и с классами, которые будем тестить и сами файлы с тестами естественно. В этот проект app добавляем строки
2. Пишем класс с юнит-тестами. 3. При билде, там, где генерятся все объектники, появляются еще *.gcda. 4. Запускаем приложение и получаем файлы *.gcno (там содержатся графы вызовов и пр). 5. Натравливаем lcov (или gcovr), которые превращают сгенерированные gcov-ом файлы в читабельный вид. В случае lcov - будет html, gcovr - xml. Правда, в случае использования последнего нужно немного помучиться с путями. В случае lcov - все ок. При использовании этих утилит нужно будет еще исключить некоторые файлы из результата (чтобы в отчетах остались только те что нужно). Вариант 2. Если тестируем библиотеку, то можно подключить ее через директиву LIBS (вместо подключения ее исходников) и далее все те то же самое. Для подключения чтобы все линковалось, возможно еще придется чутка подправить ldconfig. ЗЫ. 1. Если в проекте используется билд-система (Hudson, Jenkins, ...), то результат gcovr можно использовать в плагинах coberture coverage report - увидим красивые графики с покрытиями ну и можно посмотреть в каком файле что покрывается и сколько раз вызывались тестируемые функи. 2. В случае использования lcov - то можно просто через плагин html viewer подключить вывод lcov-а (т.к. xml генерить он не умеет, то графиков с покрытиями мы не увидим, зато будет красочный html, по которому тоже можно посмотреть что нужно). 3. Никаких ГУИ не допускается при сборке проекта с юнит-тестами (если он будет подключен к Jenkins например). Т.е. Не должно быть зависимости от X-сервера (я его поднимал на линухах). ЗЗЫ. Вещь очень прикольная, сильно сожалею что раньше не использовал юнит-тестирование, билд-систему и кучу дополнительных утилит (типа проверки дублирования кода, покрытия и пр). |
|
|
Текстовая версия | Сейчас: 22.12.2024, 19:16 |