Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×
👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Merlin: верно., но я считаю, в целом получилась плодотворно — для меня так точно.:)

Да, но это не gtest, этот макрос у них определен в своем файле code.google.com/...k/src/checks.h как и CHECK_EQ. Вообще, ASSERT_EQ, должно быть, довольно популярное имя: -) В целом, этот спор довольно далеко отклонился и я предлагаю остановиться. Я привел свои аргументы, но очевидно, что каждый решает для своего проекта сам.

Merlin: я искал

^\s*ASSERT_EQ\( language:c++

, как наверняка самый популярный макрос. первым в списке выплывает v8 — имно вполне серьезный проект. Я, кстати, за вчера очень даже проникся gtest-ом, и уже вставляю его в свой проект — в том числе и в основной код, и EXPECT_EQ тоже (в разумных пределах).

Ну, каждый проект может решать для себя. Я не вижу особых преимуществ использования gtest подобным образом, кроме унификации ассертов по всему коду. А недостатки вижу — в производительности. Обратите внимание, в gtest входит файл gtest_prod.h, он предназначен для вещей которые можно использовать в продакшн коде безо всяких оговорок. И их там совсем немного, прямо скажем одна: -)

А можно пример какого-нибудь серьезного проекта, где gtest используется прямо в продакшн коде? Даже интересно стало. Заранее спасибо.

Merlin: googletest прекрасно используется в продакшн коде, и google code search моментально находит массу примеров использования, во вполне серьезных проектах.

Вещи вроде EXPECT_EQ — несомненно, если они предназначены для использования в продакшн коде. Начиная от встроенных assert в некоторых языках до специальных библиотек позволяющих делать отключаемые ассерты/логгинг. Но, как я писал выше, конкретно gtest для этого не предназначен.

Merlin:

EXPECT_EQ является частью gtest фреймворка, который предназначен только для юнит тестов. К продакшн коду его лучше вообще не линковать, потому что он потянет за собой некоторые вещи, ухудшающие производительность. Поэтому переопределять макрос как пустой особого смысла нету, в юнит тестах ведь есть только тесты...

Похоже, в googletest проверки действительно не отключаются... Но все равно, я не вижу причин, по которым вещи вроде EXPECT_EQ из googletest не могут использоваться вне юнит тестов. Более того, я считаю, что использование проверок в живом коде (помимо тестов) — это хорошо и правильно.

Организация/автоматизация тестирования, значит. Стандартизация.

EXPECT_EQ является частью gtest фреймворка, который предназначен только для юнит тестов. К продакшн коду его лучше вообще не линковать, потому что он потянет за собой некоторые вещи, ухудшающие производительность. Поэтому переопределять макрос как пустой особого смысла нету, в юнит тестах ведь есть только тесты...

Я бы на вопрос Ambianx ответил так:, а что такое MessageBox? Под какими платформами он работает? Как анализировать его результаты? Возможна ли автоматизация работы с ним? Самый простой пример с непрерывной интеграцией вам привели выше: допустим, у вас есть 100 тестов и вы хотите каждый час получать отчет сколько из них проходят. Писать свой скрипт, который будет автоматически нажимать Ок в этом MessageBox, или как? Вот подобный вопросы и берет на себя фреймвор для тестирования, в данном случае gtest.

Ambianx:

Чет не совсем понимаю, в чем приемущество такого тестирования. Зачем писать

EXPECT_EQ(1, Factorial(0));

,если можно просто написать отладочный код

if (Factorial(0) != 1) MessageBox(...);
почему-то никто не упомянул главную причину: макрос можно отключить.

т.е. для продакшна все перекомпилируется с соотв. ключиком, и макрос определяется как пустой:

#define EXPECT_EQ(val,test)

т.е. Factorial (0) в нашем случае не будет вызван вообще.

Я думал, можно будет взять этот Google Test и с его помощью пэффективнее искать странную багу или выявить баги, которые могут проявляться не во всех случаях, а, например, в определенном месте алгоритма со специфическими данными. Зачем все усложнять, разве нельзя написать тестирующий класс без этих макросов?

Может я сильно умничаю, как для Junior-а, но все же...

Подход тут был взят для примера, а не для подхода...

Репорты — это ведь из разряда юзабилити? Мне кажется, было бы гораздо интереснее, если бы, например, эти макросы не только проверяли утверждения, маскируя стандартные средства, но и помогали понять, анализируя код, почему он неправильно работает. Или что-то такое на самом деле есть?

if (Factorial (0)! = 1) MessageBox (...);

Думаю с таким подходом continuous integration не построишь. А в макрос можно засунуть например логику, которая в зависимости от конфигурации системы автоматического тестирования будет например собирать инфу об ошибках в юнит тестах, и отсылать имейлом репорты.

А вы знаете, что там, в этом макросе? Чтобы просто сравнить два значения, много кода не нужно. Поэтому мне пока не понятно, зачем сравнение пихать в макрос.

В макросе кроме сравнения может быть все что угодно.

Т.е., это просто сравнение и в макросе EXPECT_EQ ничего «особенного» не происходит?

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

Чет не совсем понимаю, в чем приемущество такого тестирования. Зачем писать
EXPECT_EQ (1, Factorial (0));
, если можно просто написать отладочный код
if (Factorial (0)! = 1) MessageBox (...);

?

Вот интересный перевод статьи по данной тематике:

sharcus.blogspot.com/2009/09/c.html

Використовую переважно cppunit

Фреймворк хороший, больше юзаем gmock. Помогает генерилка моков, которая идет с ним (хоть и не всегда отрабатывает правильно). Из недостатков — моки очень медленно компилятся.

Підписатись на коментарі