Два набора тестов для дебажной и релизной сборки?

Question

[YoungSkipper]

Есть код который хочется покрыть тестами. Особенность приложения в том что при возникновении неких не валидных ситуаций в дебажном билде (тестируется разработчиками и внутренними тестерами) — нам предпочтительней получить краш (и большей частью краш репорт уйдет разработчику с информацией достаточной для понимания проблемы).

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

В результате с одной стороны в коде есть проверки ассертами на невалидные ситуации, но с другой стороны есть проверка возвращаемых значений, проверка входных параметров, там где нужно try/catch и т.п. — т.е. в любом случае пытаемся спасти ситуацию.

Утрированный пример — вот есть функция которая возвращает указательно некоторую структуру данных из коллекции — getBotTplById(long id)

В дебажном билде в случае отсутствия такой коллекции (не загрузился файл), или в случае если такого айди в коллекции нет (в другом месте контента есть ссылка на что-то что еще не добавили в контент) — будет ассерт и игра упадет. В релизном мы просто вернем нулевой указатель, который нужно будет проверить.

Понятно, что возможны как и ситуации когда — код ассерт написали, а вот данные проверили не везде.
Так и в целом возможны ситуации когда проверки написали, а ассерт вставить забыли.

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

Как мы пишем?

#ifdef DEBUG
ASSERT_THROW(someFunc(notValidId));
ASSERT_NOT_THROW(someFunc(validId));
#else
ASSERT_EQ(someFunc(notValidId), NULL);
ASSERT_NE(someFunc(validId), NULL);
#endif

или?

ASSERT_THROW(ASSERT_EQ(someFunc(notValidId), NULL));
ASSERT_NOT_THROW(ASSERT_NE(someFunc(validId), NULL););

Если технически получиться такое сделать.

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

Что скажете?

Answer 1

[spiritms]

Могу рассказать наш опыт. Наша тестовая система принимает на вход билд и параметр, релиз это или дебаг. Потом на этом билде выполняется какой-то сет из тестовый кейсов, при этом анализируются выходные данные, креши и логи (релиз или дебаг — это один и тот же тестовый код). Таким образом, при одинаковом коде тестовой системы, для разных билдов мы просто получаем немного разные отчёты (которые, кстати, полезно потом сравнить и сопоставить, если что-то пойдёт не так). Так же хочу заметить, что «дебажный» билд это не просто билд, который у девелоперов — это специально настроенный билд, построенный таким образом, что ассерты, эксепшены и прочая расширенная информация сбрасывается в лог, который удобно потом автоматически анализировать и формировать отчёт. Действительно, «дебажная» сборка является третим видом сборки, но она от обычной отличается только одним файлом .h с настройкой ассертов и эксепшенов. Весь этот кейс протянут через систему continious integration и проходит в автоматическом режиме. На самом деле это реализовать не так сложно, но при этом ещё проще поддерживать.

Answer 2

[abby]

На мой взгляд поведение программы должно быть одинаковым независимо от режима дебаг или релиз. В связи с этим считаю, что ручные проверки должны быть везде. Ассерты — на ваше усмотрение, они помогают лишь вовремя заметить неправильное состояние. Тесты тоже должны быть одинаковыми без #ifndef DEBUG, для этого можно использовать свои ассерты, assert.h как правило, специально написан так чтобы это можно было сделать.

Comments

[YoungSkipper]

Смотря что считать поведением. Дебажная сборка (ну может плохое название — назовем ее разработческой/тестовой) — это куча дополнительно визуальной информации, куча счетчиков начиная от fps и текстурной памяти, до графиков сколько тот или иной логический блок времени выполняется, внутренние логи, визальная дополнительная информация, доступ к функция не доступным для пользователям для облегчения тестирования и т.п. Ну и работает он по понятным причинам в разы медленней.

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

Максима что проверки должны быть везде тоже хороша. Собственно тесты это и помогают проверить.

Но вопрос как такие тесты организовать, собственно остался открытым.

Хотя возможно я не понял вас — можно на примере вот функции которой я описал?

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

Как писать тесты?

Answer 3

[abby]

Может быть не стоит тестировать то, что приложение должно крэшиться? Для юнит-тестов заведите ассерты, которые никогда не бросают исключений, а пишут, например, в специальный лог. Понимаю, что иногда баг очень сложно воспроизвести, и записи в логе недостаточно. Для таких случаев («сложного» интеграционного тестирования со случайными данными и тестеров, которые анализируют доп. информацию в дебажной версии) можно использовать реализацию ассерта, которая крэшит приложение, чтобы девелоперы потом могли по дампу выявить причину падения.

Comments

[YoungSkipper]

Ассерты которые пишут в специальный лог это как бы ок — но тогда тесты будут тестировать какую-то третью сборку. Т.е. есть дебажная в которой ассерты крашат приложение, релизное где ассертов нет и третья где ассерты пишут в лог.

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

Мы сейчас говорим о автоматических тестах все таки.

Да и проблема с тестами которые _должны_ вызывать ассерт? В дебаге — посмотри что в лог добавилась запись, а в релизе что не добавилась? Т.е. опять две реализации теста?

Второе предложение не понял. Сейчас ассерты в дебажной версии как раз и крашат приложения (на то они и ассерты).

[YoungSkipper]

И собственно почему не тестировать то, на то что должно крашнуться.
Тесты вроде как нужно писать и на валидные случае, и не на валидные.

Если логика функции написана так, что в дебаге она должна крашнуться — то на это нужно написать как бы тест на это, нет?

Answer 4

[Николай Турнавиотов]

Мне кажется, что дебаг вариант от релиза должен отличаться не тестами, а генерацией логов по каждому чиху, в зависимости от его уровня, а тесты должны быть одинаковы, ну и выводить или нет «тестовый fps».
А тестам должно быть без разницы, релиз это или дебаг, и если тест валится — это кейс для разбирательства «где косяк?», и если не валится, значит всё ок. Ну и собственно, студия имеет интересную настройку — не пускать сборку в TFS, если код не компилится корректно

Comments

[YoungSkipper]

Ээээ, про логи я согласен, и согласен, что тестам должно быть без разницы. Вопрос в том как написать такие тесты. Можно примет?

Вот есть функция которая возвращает указательно на объект по некоторому ключу из мапы. Если мапы нету или объекта по данному ключу нету — в релизе возвращает нулевой указатель, в дебаге кидает экцепшин. В если в мапе по данному ключу есть объект возвращает его.

Мы знаем заведомо валидные и заведомо не валидные значения ключа.

Как написать тест, чтобы «без разницы, релиз это или дебаг»?

[abby]

в релизе возвращает нулевой указатель, в дебаге кидает экцепшин

Я считаю, что лучше не стоит иметь разный тип логики в релизе и в дебаге. В вашем случае в релизе и в тестах вы сравниваете возвращаемое значение с nullptr, а в дебаге логика основана на исключениях. Либо всегда бросайте исключения, либо всегда проверяйте возвращаемое значение.
тесты:

EXPECT_EQ(nullptr, domainModel.getDocumentById(invalidId));
auto document = domainModel.getDocumentById(validDocumentId);
ASSERT_TRUE(nullptr != document);

в клиентском коде:

auto document = domainModel.getDocumentById(documentId);
if (nullptr != document) {
  // do all business here
}

[Николай Турнавиотов]

я за проверку значений

[YoungSkipper]

Как-то у нас не складывается :) Максимума — «всегда проверяйте возвращаемое значение» хороша, но не работает.

Никакой логики основной на исключениях нету, исключенние/ассерт — это способ аварийно завершить программу послав сигнал SIGABRT- после чего будет получен дамп. Это единственный способ получить какие либо данные c устройства.

Второй способ — это визуальные наблюдения тестера — если ассерта не будет, он может заметить, что при определенной комбинации дейсвий определенный визуальный сигнал не появился (лампочка не зажглась если утрировать).

Т.е. еще раз — либо SIGABRT, либо визуальные наблюдения тестера.

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

Это вводная.

Поэтому у нас два варианта — либо мы вставляем ассерт внутри getDocumentById — всегда зная что она не должна возвращать нулевое значение. И тогда в этом случае автоматом при определенной комбинации действий пользователя мы получим свое сообщение о ошибке в виде дампа. Либо мы надеемся что тестер сможет визуально определить что кусок с // do all business here" не выполнился и отрапортавать нам.

Естственно первый вариант лучше :)

P.S. Но всем спасибо, да :)