Comments 29
Плохо, что надо main() собственноручно писать, а такдовольно неплохая библиотека — надо будет посмотреть на досуге.
Не в курсе: для NetBeans нет похожих плагинов?
Не в курсе: для NetBeans нет похожих плагинов?
main() меня лично не сильно напрягает. Я один раз написал его, передрав из хелпа, после чего только добавляю кейсы. Для всего набора тестов имею отдельную цель сборки, которая компилится и запускается одним кликом.
Насчёт плагина для NetBeans не в курсе, но можно использовать, например, QtTestRunner
Насчёт плагина для NetBeans не в курсе, но можно использовать, например, QtTestRunner
main() меня лично не сильно напрягает. Я один раз написал его, передрав из хелпа, после чего только добавляю кейсы. Для всего набора тестов имею отдельную цель сборки, которая компилится и запускается одним кликом.
Насчёт плагина для NetBeans не в курсе, но можно использовать, например, QtTestRunner
Насчёт плагина для NetBeans не в курсе, но можно использовать, например, QtTestRunner
На GoogleTest не смотрели? К нему ещё GoogleMock есть.
Нашёл в википедии сравнение фреймворков для тестирования. Думаю, многим интересно будет;)
можно использовать Boost::Test, но качать придётся целиком
кто-то до сих пор программирует на С++ без использования Boost? O_o
вы не поверите
а почему? он реально упрощает разработку, качество на уровне(правда есть уж очень накрученные либы, но их в счет не берем), а о степени важности говорит передирание некоторых основных либ в новый стандарт. Так почему его не юзают?
Имел дело с регулярными выражениями и библиотекой для работы со временем из Boost — всё таки они довольно накручены и сложноваты. Да мощное средство, но порой нужно решить конкретную типовую задачу, а не ковырятся в настройках библиотеки, в таких ситуациях Boost не очень хорош.
Если же мы делаем программу с графическим интерфейсом, то смысл от Boost? Многое из него есть в QT и MFC?
У Apache есть своя библиотека. Тоже можно посмотреть на досуге;)
Если же мы делаем программу с графическим интерфейсом, то смысл от Boost? Многое из него есть в QT и MFC?
У Apache есть своя библиотека. Тоже можно посмотреть на досуге;)
у boost наиболее важные либы это — bind, умные указатели, thread. Без них вообще не представляю программ. Особенно без smart_pointer'ов. Вы до сих пор программируете на чистых указателях и следите за освобождением памяти вручную? for_each тоже очень удобен.
В графических приложениях толку естественно мало. Но есть signal и function для обработчиков вполне пригодные.
На счет date — ну хз. По мне вполне удобная либа. Регэкспы не использовал, ничего не скажу. А вообще в большинстве бустовых либ нужно потратить несколько дней на разбор — и можно идти в бой, что в конце концов сэкономит просто кучу времени.
В графических приложениях толку естественно мало. Но есть signal и function для обработчиков вполне пригодные.
На счет date — ну хз. По мне вполне удобная либа. Регэкспы не использовал, ничего не скажу. А вообще в большинстве бустовых либ нужно потратить несколько дней на разбор — и можно идти в бой, что в конце концов сэкономит просто кучу времени.
добавлю по поводу boost::test, так как уж очень поверхностно рассмотрен фреймворк:
1) можно делать тестовые проекты как с main так и без
2) можно делать как автоматическое тестирование методов, так и ручное
3) вывод возможен как в обычном текстовом виде так и в xml
4) Есть счетчик времени исполнения тестов
5) Настраивается что и как и куда выводится
вот пример из проекта:
вот пример вполне самостоятельного тестового файла. Никаких лишних телодвижений:
1) Компилируем проект
2) Перенаправляем вывод в текстовый файл или запускаем через свою утилиту для визуализации резульатов
3) ???
4) PROFIT
ИМХО очень даже юзабельный фреймворк. Не хватает только времени доделать свой гуй и сделать простенький аддон для студии для перехода к проваленным ассертам. Сам тест элементарно можно запускать использовав Post-Build Event. Нетбинс и эклипс не использую, не исключаю, что там уже есть плагины для этого фреймворка.
1) можно делать тестовые проекты как с main так и без
2) можно делать как автоматическое тестирование методов, так и ручное
3) вывод возможен как в обычном текстовом виде так и в xml
4) Есть счетчик времени исполнения тестов
5) Настраивается что и как и куда выводится
вот пример из проекта:
#include <boost/test/unit_test.hpp>
#include "stdafx.h"
BOOST_AUTO_TEST_SUITE(rectangle_test)
BOOST_AUTO_TEST_CASE( rectangle_intersect_check)
{
const geometry::Rectangle rec1(geometry::Point(0, 10), 5, 10);
const geometry::Rectangle rec2(geometry::Point(0, 15), 5, 10);
geometry::Rectangle result;
const geometry::Rectangle expected_rectangle(geometry::Point(0, 10), 5, 5);
BOOST_CHECK( geometry::Rectangle::intersect(rec1, rec2, result) );
BOOST_CHECK(result == expected_rectangle);
result = rec1 & rec2;
BOOST_CHECK(result == expected_rectangle);
}
BOOST_AUTO_TEST_SUITE_END() вот пример вполне самостоятельного тестового файла. Никаких лишних телодвижений:
1) Компилируем проект
2) Перенаправляем вывод в текстовый файл или запускаем через свою утилиту для визуализации резульатов
3) ???
4) PROFIT
ИМХО очень даже юзабельный фреймворк. Не хватает только времени доделать свой гуй и сделать простенький аддон для студии для перехода к проваленным ассертам. Сам тест элементарно можно запускать использовав Post-Build Event. Нетбинс и эклипс не использую, не исключаю, что там уже есть плагины для этого фреймворка.
Согласен. Очень удобный фреймворк. Сам его использую.
Плагины для перехода на проваленные ассерты не нужны, все реализуется штатными средствами: при запуске по post-build event, boost::test выдает ошибки в формате который студия распознает как обычные ошибки компиляции.
Посоветуйте tutorial'ы и Get Statrted сатьи по Boost::Test?
ну помойму туториал от разработчика вполне пригодный для начала. понять основы можно. Ну и плюс немного эспериментов с тем, что не очень понятно даёт вполне полную картину о работе с этим фреймворком.
ссылка
ссылка
Фреймворков для C++, как уже писал, огромное множество — выбирай не хочу. Лично мне, по душе больше xUnit- подобные, т.к. поудобнее и нагляднее организован сам тест.
Не очень понятен пункт:
Перенаправляем вывод в текстовый файл или запускаем через свою утилиту для визуализации резульатов
Стандартного визуализатора нет?
P.S.
Вы не против, если я помещу в статью ваши добавления?
Не очень понятен пункт:
Перенаправляем вывод в текстовый файл или запускаем через свою утилиту для визуализации резульатов
Стандартного визуализатора нет?
P.S.
Вы не против, если я помещу в статью ваши добавления?
Немножко не в тему, но можно я все-таки спрошу.
Как вообще по-фэншую писать юнит-тесты для методов сложных COM-объектов которые, например, в качестве результата имеют не какое-то возвращаемое значение, а изменение состояния каких-то других объектов или просто UI?
Или тестирование COM-объектов уже не попадает под понятие юнит-тестирования?
Как вообще по-фэншую писать юнит-тесты для методов сложных COM-объектов которые, например, в качестве результата имеют не какое-то возвращаемое значение, а изменение состояния каких-то других объектов или просто UI?
Или тестирование COM-объектов уже не попадает под понятие юнит-тестирования?
Точно так же, как и для всех других объектов. Если метод меняет состояние, то это можно как-то обнаружить с помощью других методов. Вот через них и проверяем. А если изменение состояния нельзя обнаружить (в случае кэширования), то проверяем что ничего не изменилось или вводим метод (это разрушает инкапсуляцию, но что делать), через которое изменение обнаружить можно.
А юнит-тестирование UI — это всегда очень большая проблема.
А юнит-тестирование UI — это всегда очень большая проблема.
Универсального ответа нет.
Но есть очень хорошая книга Working Effectively with Legacy Code. Книга построена в виде сборника рецептов, в ней есть, например, такие главы как I Can't Get This Class into a Test Harness и I Can't Run This Method in a Test Harness. Очень рекомендую.
Но есть очень хорошая книга Working Effectively with Legacy Code. Книга построена в виде сборника рецептов, в ней есть, например, такие главы как I Can't Get This Class into a Test Harness и I Can't Run This Method in a Test Harness. Очень рекомендую.
Думаю, вам стоит смотреть в сторону mock-объектов.
Сам на практике ещё не применял — поэтому не могу посоветовать что-то более конкретное.
Сам на практике ещё не применял — поэтому не могу посоветовать что-то более конкретное.
Sign up to leave a comment.
О модульном тестировании на C++ и о CxxTest