О модульном тестировании на C++ и о CxxTest

[Blackened]

Юзаю CppUnit. Библиотека не громоздкая. Для запуска тестов не требуется препроцессинга, только простая сборка бинарника-тестера.

Для него в Eclipse есть плагин ECUT, который визуализирует результаты тестирования. В сочетании с ним в Эклипсе всё выглядит точь-в-точь как JUnit для Java.

[AlpenColt]

Плохо, что надо main() собственноручно писать, а такдовольно неплохая библиотека — надо будет посмотреть на досуге.

Не в курсе: для NetBeans нет похожих плагинов?

[Blackened]

main() меня лично не сильно напрягает. Я один раз написал его, передрав из хелпа, после чего только добавляю кейсы. Для всего набора тестов имею отдельную цель сборки, которая компилится и запускается одним кликом.

Насчёт плагина для NetBeans не в курсе, но можно использовать, например, QtTestRunner

[Blackened]

main() меня лично не сильно напрягает. Я один раз написал его, передрав из хелпа, после чего только добавляю кейсы. Для всего набора тестов имею отдельную цель сборки, которая компилится и запускается одним кликом.

Насчёт плагина для NetBeans не в курсе, но можно использовать, например, QtTestRunner

[Blackened]

Извиняюсь, дубль…

[Paul]

На GoogleTest не смотрели? К нему ещё GoogleMock есть.

[AlpenColt]

Смотрел — показался чем-то похожим на Boost, хотя и разные подходы.
По сравнению с cxxtest, на мой взгляд, нужно писать больше кода, хотя само средство помощнее будет.

[burivuh]

Недавно начал внедрять TDD, в выборе тест фреймворка остановился как раз на GoogleTest Framework. Мне нравится )

[AlpenColt]

Нашёл в википедии сравнение фреймворков для тестирования. Думаю, многим интересно будет;)

[kolobog007]

можно использовать Boost::Test, но качать придётся целиком

кто-то до сих пор программирует на С++ без использования Boost? O_o

[burivuh]

вы не поверите

[kolobog007]

а почему? он реально упрощает разработку, качество на уровне(правда есть уж очень накрученные либы, но их в счет не берем), а о степени важности говорит передирание некоторых основных либ в новый стандарт. Так почему его не юзают?

[AlpenColt]

Имел дело с регулярными выражениями и библиотекой для работы со временем из Boost — всё таки они довольно накручены и сложноваты. Да мощное средство, но порой нужно решить конкретную типовую задачу, а не ковырятся в настройках библиотеки, в таких ситуациях Boost не очень хорош.

Если же мы делаем программу с графическим интерфейсом, то смысл от Boost? Многое из него есть в QT и MFC?

У Apache есть своя библиотека. Тоже можно посмотреть на досуге;)

[kolobog007]

у boost наиболее важные либы это — bind, умные указатели, thread. Без них вообще не представляю программ. Особенно без smart_pointer'ов. Вы до сих пор программируете на чистых указателях и следите за освобождением памяти вручную? for_each тоже очень удобен.

В графических приложениях толку естественно мало. Но есть signal и function для обработчиков вполне пригодные.

На счет date — ну хз. По мне вполне удобная либа. Регэкспы не использовал, ничего не скажу. А вообще в большинстве бустовых либ нужно потратить несколько дней на разбор — и можно идти в бой, что в конце концов сэкономит просто кучу времени.

[kolobog007]

добавлю по поводу boost::test, так как уж очень поверхностно рассмотрен фреймворк:
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. Нетбинс и эклипс не использую, не исключаю, что там уже есть плагины для этого фреймворка.

[Slaffko]

Согласен. Очень удобный фреймворк. Сам его использую.

[lige]

Плагины для перехода на проваленные ассерты не нужны, все реализуется штатными средствами: при запуске по post-build event, boost::test выдает ошибки в формате который студия распознает как обычные ошибки компиляции.

[kolobog007]

опа, чтото я не проверял этого момента, спасибо.

[Sonic_SE]

Посоветуйте tutorial'ы и Get Statrted сатьи по Boost::Test?

[kolobog007]

ну помойму туториал от разработчика вполне пригодный для начала. понять основы можно. Ну и плюс немного эспериментов с тем, что не очень понятно даёт вполне полную картину о работе с этим фреймворком.

ссылка

[AlpenColt]

Фреймворков для C++, как уже писал, огромное множество — выбирай не хочу. Лично мне, по душе больше xUnit- подобные, т.к. поудобнее и нагляднее организован сам тест.

Не очень понятен пункт:
Перенаправляем вывод в текстовый файл или запускаем через свою утилиту для визуализации резульатов
Стандартного визуализатора нет?

P.S.
Вы не против, если я помещу в статью ваши добавления?

[kolobog007]

Стандартного визуализатора нет?

нету. просто компилится обычная консольная программа.

Вы не против, если я помещу в статью ваши добавления?

нет, не против.

[burivuh]

Немножко не в тему, но можно я все-таки спрошу.
Как вообще по-фэншую писать юнит-тесты для методов сложных COM-объектов которые, например, в качестве результата имеют не какое-то возвращаемое значение, а изменение состояния каких-то других объектов или просто UI?
Или тестирование COM-объектов уже не попадает под понятие юнит-тестирования?

[halyavin]

Точно так же, как и для всех других объектов. Если метод меняет состояние, то это можно как-то обнаружить с помощью других методов. Вот через них и проверяем. А если изменение состояния нельзя обнаружить (в случае кэширования), то проверяем что ничего не изменилось или вводим метод (это разрушает инкапсуляцию, но что делать), через которое изменение обнаружить можно.

А юнит-тестирование UI — это всегда очень большая проблема.

[Paul]

Универсального ответа нет.

Но есть очень хорошая книга 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. Очень рекомендую.

[burivuh]

Скачал, почитаю, спасибо )

[AlpenColt]

Думаю, вам стоит смотреть в сторону mock-объектов.
Сам на практике ещё не применял — поэтому не могу посоветовать что-то более конкретное.

[burivuh]

Смотрел, но что-то не получилось вникнуть быстро. А проект в авральном режиме… как обычно вобщем-то )