Google testing framework (gtest)

[aviaconstructor]

Всем рекоммендую. Google testing framework позволяет сконцентрироваться непосредственно на тестах — минимум тупой писанины, не относящейся к вашей предметной области. Многим не нравятся макро — это только вначале. На самом деле всё очень рационально, и благодаря им, вывод ошибок вестма приятен

[nikel]

Сам по себе Google C++ Testing Framework мало полезен. Если принять во внимание тот факт, что модульные тесты должны быть неинвазивными (т.е. никаких необратимых изменений среды); то его сфера применения окажется очень узкой.

Я бы посмотрел сразу в сторону Google C++ Mocking Framework, который уже включает в себя googletest.

[nikel]

От требования неинвазивности избавиться нельзя в принципе. Если модульный тест не способен обеспечить неизменяемые условия проверки, то зачем он нужен?

Что касается mock'ов, то я вовсе не призываю использовать их везде и повсюду. Можно конечно и без них, если требуется покрыть тестами только успешные сценарии.

Если требуется достичь максимального покрытия и моделировать стрессовые ситуации для различных участков кода, то здесь без mock'ов не обойтись.

Сам я уже не помню, когда использовал googletest отдельно от googlemock.

[sgzmd]

Боже, я никогда не думал что увижу эту картинку (которая мне все глаза уже намозолила) на Хабре! :-)

[hoxnox]

Да, за картинку я уже отхватил в карму. =) Ну что поделать, если это, так сказать, официальная картинка фреймворка…

[BiTHacK]

hoxnox, а Вы не смотрели средства тестирования, встроенные в qt? Хотелось бы увидеть сравнение подобного инструментария.

[hoxnox]

Даже Qt-шные приложения я тестировал boost::test'ом, так что ничего сказать не могу. Но спасибо, что напомнили о наличии в Qt тестов.

[4pcbr]

кажется, лучшее решение для скетч-приложений

[9mm]

Жалко в C++0x не добавили базовой функциональности для юнит-тестирования. Фреймворк это хорошо, но встроенная поддержка работает лучше и избавляет от несовместимости разных фреймворков. Как в D например:

class Foo
{
private int k;
public void dosomething();
}

unittest
{
Foo foo;

foo.dosomething();

assert( foo.k < 9 && foo.k > 0 ); // приватная переменная видна
}


Здорово же.

[hoxnox]

По-моему дух программирования на C++ предполагает использование конкретных библиотек для решения конкретных задач.

[9mm]

Дух программирования на C++ слишком силён :). (А я ведь почти фанат этого языка)

Нет, серьёзно, главная лозунг C++ это «не плати за то, чем не пользуешся». Встроенные юнит-тесты ему не противоречат.

Минус использования сторонних библиотек думаю очевиден — проблемно перетащить код в другой проект.
Это как в C — какой бы не был проект в нём обязательно будет определён тип ИМЯ_ПРОЕКТА_BOOL — вроде бы фигня, но этот зоопарк раздражает.

[yuriv]

В С++0х не вкдючили и более серъёзные вещи, например, концепции за которые ратовал сам Страуструп и просил их включить хотя бы как опшионал. Не включили модули, хотя всем очевидно, что это как раз то, чего не хватает с и с++, и вот это как раз нисколько с/с++ не испортило бы. Первое сильно продвинуло бы вперёд метапрограммирование и параметрический полиморфизм вместо стандартной модели наследования и ад-хок полиморфизма, а второе позволило бы навести порядок с единицами трансляции и заголовочными файлами.

[nikel]

hoxnox, очень жаль, что обошли вниманием такую не очевидную вещь, как флаги.

[hoxnox]

Вы совершенно правы, чуть не пропустил одну из самых вкусных плюшек. Спасибо. Обновил.

[nikel]

Вам спасибо за краткую и содержательную статью.

[begoon]

Подборочка постов про Google Test на русском языке:

easy-coding.blogspot.com/search/label/gtest

Немного переведенной документации по Google Test and Google Mock:

code.google.com/p/googletest-translations/

[Akenfold]

Кстати, для запуска тестов есть уже готовый исходник ${GTEST_DIR}/src/gtest_main.cc, содержащий функцию main, где производится инициализация фреймворка и запуск тестов:

#include <iostream>

#include "gtest/gtest.h"

GTEST_API_ int main(int argc, char **argv) {
  std::cout << "Running main() from gtest_main.cc\n";

  testing::InitGoogleTest(&argc, argv);
  return RUN_ALL_TESTS();
}

Очень удобно. Просто пишешь тесты, а при сборке указываешь компилятору этот файл. Мелочь, а приятно.

[Sveolon]

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

int main(int argc, char *argv[])
{
// For Android ADB
std::ios_base::sync_with_stdio(false);

testing::InitGoogleTest(&argc, argv);

// Force print tests times
testing::GTEST_FLAG(print_time) = true;

// Filter tests
testing::GTEST_FLAG(filter) = "LoggerTst.*";

return RUN_ALL_TESTS();
}


[kibork]

Некоторое время назад перешел на unittest++
Он очень хороше подходит для случаев когда дополнительный функционал не нужен а хочется простоты.

TEST(UnitTestName) {
//Any code
}

это все что нужно для написания теста. Это позволяет очень быстро их строчить, что у меня очень положительно сказывается на их количестве и вообще использованиями — быстрее написать тест чем запустить.
Также очень хороший вывод результатов и ошибок.

для проверок доступны простые макросы
CHECK(condition), condition == true
CHECK_EQUAL(expected, actual) — любые типы данных
CHECK_CLOSE(expected, actual, tolerance) — для проверки double/float
CHECK_ARRAY_EQUAL(expected, actual, count)
CHECK_ARRAY_CLOSE(expected, actual, count, tolerance)
CHECK_THROW(expression, ExpectedExceptionType)

Советую посмотреть тем кто хочеть простоты и не нуждается в больших возможностях.
Что еще приятно в линукс системах подключается просто добавление библиотеки.

[hoxnox]

А чем сложнее линковаться с gtest вместо unittest++'овской библиотечки и использовать их gtest assert'ы и expect'ы вместо check'ов? По-моему сложность такая же, а в выхлопе куча потенциальных (если вы их не используете) возможностей.

[vaedermakar]

Привет, подскажи пожалуйста, как увеличить лимит на тест?? (по дефолту тест длится не дольше минуты)