Unit-test-ы для C++
Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті
Хочу понять, какие инструменты наиболее популярны и за что.
Что думаете насчет Google Test? — Первое слово внушает доверие.:)
Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті
Хочу понять, какие инструменты наиболее популярны и за что.
Что думаете насчет Google Test? — Первое слово внушает доверие.:)
Merlin: верно., но я считаю, в целом получилась плодотворно — для меня так точно.:)
Да, но это не gtest, этот макрос у них определен в своем файле code.google.com/...k/src/checks.h как и CHECK_EQ. Вообще, ASSERT_EQ, должно быть, довольно популярное имя: -) В целом, этот спор довольно далеко отклонился и я предлагаю остановиться. Я привел свои аргументы, но очевидно, что каждый решает для своего проекта сам.
Merlin: я искал
^\s*ASSERT_EQ\( language:c++
, как наверняка самый популярный макрос. первым в списке выплывает v8 — имно вполне серьезный проект. Я, кстати, за вчера очень даже проникся gtest-ом, и уже вставляю его в свой проект — в том числе и в основной код, и EXPECT_EQ тоже (в разумных пределах).
А можно пример какого-нибудь серьезного проекта, где gtest используется прямо в продакшн коде? Даже интересно стало. Заранее спасибо.
Merlin: googletest прекрасно используется в продакшн коде, и google code search моментально находит массу примеров использования, во вполне серьезных проектах.
Вещи вроде EXPECT_EQ — несомненно, если они предназначены для использования в продакшн коде. Начиная от встроенных assert в некоторых языках до специальных библиотек позволяющих делать отключаемые ассерты/логгинг. Но, как я писал выше, конкретно gtest для этого не предназначен.
Merlin:
EXPECT_EQ является частью gtest фреймворка, который предназначен только для юнит тестов. К продакшн коду его лучше вообще не линковать, потому что он потянет за собой некоторые вещи, ухудшающие производительность. Поэтому переопределять макрос как пустой особого смысла нету, в юнит тестах ведь есть только тесты...
Похоже, в googletest проверки действительно не отключаются... Но все равно, я не вижу причин, по которым вещи вроде EXPECT_EQ из googletest не могут использоваться вне юнит тестов. Более того, я считаю, что использование проверок в живом коде (помимо тестов) — это хорошо и правильно.
Я бы на вопрос Ambianx ответил так:, а что такое MessageBox? Под какими платформами он работает? Как анализировать его результаты? Возможна ли автоматизация работы с ним? Самый простой пример с непрерывной интеграцией вам привели выше: допустим, у вас есть 100 тестов и вы хотите каждый час получать отчет сколько из них проходят. Писать свой скрипт, который будет автоматически нажимать Ок в этом MessageBox, или как? Вот подобный вопросы и берет на себя фреймвор для тестирования, в данном случае gtest.
Ambianx:
Чет не совсем понимаю, в чем приемущество такого тестирования. Зачем писать
EXPECT_EQ(1, Factorial(0));
,если можно просто написать отладочный код
if (Factorial(0) != 1) MessageBox(...);
почему-то никто не упомянул главную причину: макрос можно отключить.т.е. для продакшна все перекомпилируется с соотв. ключиком, и макрос определяется как пустой:
#define EXPECT_EQ(val,test)
т.е. Factorial (0) в нашем случае не будет вызван вообще.
Может я сильно умничаю, как для Junior-а, но все же...
Репорты — это ведь из разряда юзабилити? Мне кажется, было бы гораздо интереснее, если бы, например, эти макросы не только проверяли утверждения, маскируя стандартные средства, но и помогали понять, анализируя код, почему он неправильно работает. Или что-то такое на самом деле есть?
if (Factorial (0)! = 1) MessageBox (...);
Думаю с таким подходом continuous integration не построишь. А в макрос можно засунуть например логику, которая в зависимости от конфигурации системы автоматического тестирования будет например собирать инфу об ошибках в юнит тестах, и отсылать имейлом репорты.
А вы знаете, что там, в этом макросе? Чтобы просто сравнить два значения, много кода не нужно. Поэтому мне пока не понятно, зачем сравнение пихать в макрос.
Т.е., это просто сравнение и в макросе EXPECT_EQ ничего «особенного» не происходит?
Ну хотя бы тем что вывод можно будет перенаправить в файл при необходимости, а у тебя хардкод получается.
?
Фреймворк хороший, больше юзаем gmock. Помогает генерилка моков, которая идет с ним (хоть и не всегда отрабатывает правильно). Из недостатков — моки очень медленно компилятся.
21 коментар
Додати коментар Підписатись на коментаріВідписатись від коментарів