Pull to refresh

Comments 23

Всем рекоммендую. Google testing framework позволяет сконцентрироваться непосредственно на тестах — минимум тупой писанины, не относящейся к вашей предметной области. Многим не нравятся макро — это только вначале. На самом деле всё очень рационально, и благодаря им, вывод ошибок вестма приятен
Сам по себе Google C++ Testing Framework мало полезен. Если принять во внимание тот факт, что модульные тесты должны быть неинвазивными (т.е. никаких необратимых изменений среды); то его сфера применения окажется очень узкой.

Я бы посмотрел сразу в сторону Google C++ Mocking Framework, который уже включает в себя googletest.
А как моки позволяют избавиться от неинвазивности и почему это нельзя сделать без них? Я бы сто раз подумал, прежде чем браться за моки.
От требования неинвазивности избавиться нельзя в принципе. Если модульный тест не способен обеспечить неизменяемые условия проверки, то зачем он нужен?

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

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

Сам я уже не помню, когда использовал googletest отдельно от googlemock.
Да, стрессовые ситуации это как раз тот случай, когда без моков нельзя.
Боже, я никогда не думал что увижу эту картинку (которая мне все глаза уже намозолила) на Хабре! :-)
Да, за картинку я уже отхватил в карму. =) Ну что поделать, если это, так сказать, официальная картинка фреймворка…
hoxnox, а Вы не смотрели средства тестирования, встроенные в qt? Хотелось бы увидеть сравнение подобного инструментария.
Даже Qt-шные приложения я тестировал boost::test'ом, так что ничего сказать не могу. Но спасибо, что напомнили о наличии в Qt тестов.
кажется, лучшее решение для скетч-приложений
Жалко в C++0x не добавили базовой функциональности для юнит-тестирования. Фреймворк это хорошо, но встроенная поддержка работает лучше и избавляет от несовместимости разных фреймворков. Как в D например:

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

unittest
{
Foo foo;

foo.dosomething();

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


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

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

Минус использования сторонних библиотек думаю очевиден — проблемно перетащить код в другой проект.
Это как в C — какой бы не был проект в нём обязательно будет определён тип ИМЯ_ПРОЕКТА_BOOL — вроде бы фигня, но этот зоопарк раздражает.
В С++0х не вкдючили и более серъёзные вещи, например, концепции за которые ратовал сам Страуструп и просил их включить хотя бы как опшионал. Не включили модули, хотя всем очевидно, что это как раз то, чего не хватает с и с++, и вот это как раз нисколько с/с++ не испортило бы. Первое сильно продвинуло бы вперёд метапрограммирование и параметрический полиморфизм вместо стандартной модели наследования и ад-хок полиморфизма, а второе позволило бы навести порядок с единицами трансляции и заголовочными файлами.
hoxnox, очень жаль, что обошли вниманием такую не очевидную вещь, как флаги.
Вы совершенно правы, чуть не пропустил одну из самых вкусных плюшек. Спасибо. Обновил.
Вам спасибо за краткую и содержательную статью.
Кстати, для запуска тестов есть уже готовый исходник ${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();
}

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

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();
}
Некоторое время назад перешел на 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)

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

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

Sign up to leave a comment.

Articles