Какой фреймворк для модульных тестов для игр на c ++ [закрыто]

Какую комбинацию инструментов тестирования вы считаете лучшей? Учитывая рамки / библиотеки на ваш выбор, вы можете рассмотреть:

• пригодность для TDD
• простота использования / производительность
• работа с фиктивными объектами
• настройка с непрерывной интеграцией
• Отчет об ошибках

Примечание. Хотя это потенциально общий вопрос, такой как вопрос о SO, я бы сказал, что разработка игр обычно связана с определенным рабочим процессом, который влияет на выбор для тестирования. Для более высокого уровня, смотрите вопрос Автоматическое тестирование игр .

Я обнаружил, что с UnitTest ++ очень легко работать. Мне все еще придется попробовать amop вместе с ним, который, как упоминалось, является хорошим компаньоном для UnitTest ++ для функциональности ложных объектов. В противном случае Google Mock является популярным выбором. Кроме того, вы можете прочитать о UnitTest ++ и Mock Objects .

UnitTest ++ может быть настроен с вашим подходом непрерывной интеграции, например, с Hudson

Возможно, вы захотите прочитать этот вдохновляющий пост, если вы не уверены, что юнит-тестирование и игры идут хорошо.

Еще один голос за UnitTest ++ . Очень легко интегрировать, скомпилировать для нашей целевой встраиваемой платформы очень легко, просто и удобно. Мы также интегрировали его с Hudson. Мы посмотрели на GoogleTest, но отклонили его (я думаю, что у него были проблемы с компиляцией для нашей целевой платформы), но он имеет аналогичный набор функций и может подойти для вас.

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

Когда я работал в C ++ (отказ от ответственности: это было около 2005 года), я использовал слегка измененную версию TUT (Template Unit Test Framework) . Мне понравилось, потому что он был настолько легким, что его было легко модифицировать, и означал, что при написании тестов требовалось очень мало «клея».

Вот одна очень простая модификация, которую я сделал, которая позволяет писать тесты еще проще:

static int BogusFunction() { return __COUNTER__; } // Increment the __COUNTER__ to the correct position for the begining of the tests
#define TEST template<> template<> void object::test<__COUNTER__>()
#define ENSURE(msg, cond) ensure(msg, cond, __FILE__, __LINE__)
#define ENSURE_EQUALS(msg, actual, expected) ensure_equals(msg, actual, expected, __FILE__, __LINE__)
#define ENSURE_DISTANCE(msg, actual, expected, distance) ensure_distance(msg, actual, expected, distance, __FILE__, __LINE__)
#define FAIL(msg) fail(msg, __FILE__, __LINE__)

Другое изменение, которое я сделал, касалось его выходного формата, чтобы ошибки теста правильно отображались в списке ошибок Visual Studios (при запуске как часть сборки), щелкая по которому можно было перейти к файлу и строке неудачного теста.

(Способность делать подобные вещи означает, что она может быть приспособлена к вашему процессу TDD / CI, а не заставлять вас встраиваться в него.)

Вот пример теста (из стека команд из моего редактора):

TEST // Undoing a command
{
    cs.AddCommand(new TestCommand);
    cs.AddCommand(new TestCommand(od));

    ENSURE("Undo success", cs.Undo());
    ENSURE_EQUALS("Stack size", cs.size(), 2);
    ENSURE_EQUALS("Command's Undo() was called", od.undo, 1);
    ENSURE_EQUALS("Command's Redo() not called", od.redo, 0);

    ACommandStack::const_iterator it = cs.end();
    ENSURE("Command is redoable", cs.GetUndoPos() == --it);
}

(В приведенном выше коде, csи odявляются модулями для каждого модуля, и TestCommandявляется фиктивным объектом.)

Когда дело доходит до C ++, я попробовал и использовал каркас Googletest, http://code.google.com/p/googletest/ . Он прост в настройке, прост в использовании и отлично работает.

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

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

Следующим в моем списке является Boost Test . API теста Google немного более современен, чем Boost.Test, но Boost Test проделал потрясающую работу, добавив новые функции и отказавшись от жесткой парадигмы CppUnit.

Я также использовал CxxTest . Он довольно хорошо сделан, но вы можете сказать, что он не такой современный, как Boost.Test или Google Test. В частности, его поддержка тестовых наборов и приспособлений немного неудобна.

Мне нравится использовать расширенные функции, но если вы минималист, вы никогда не увидите разницу между ними. Большинство моих коллег были бы довольны структурой модульных тестов, которая поддерживает тест автоматической регистрации (декларативным способом) и имеет своего рода макрос CHECK_EQUALS (a, b).

Моя любимая библиотека для тестирования - QuickCheck http://en.wikipedia.org/wiki/QuickCheck . Существует экспериментальная версия C ++, но она выглядит слишком тяжелой, но даже без специальной библиотеки принципы просты в использовании.

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

Он не заменяет традиционные модульные тесты (он уменьшает потребность во многих потенциальных модульных тестах), но это отличный способ обнаружить ошибки и помогает провести стресс-тестирование моей стратегии выделения памяти (вместе с Valgrind). Здорово наблюдать, как выходит более миллиона ассигнований на Valgrind pure :).

Раньше я использовал CxxTest в качестве тестового жгута, который мне понравился. Теперь все мои тесты являются отдельными бывшими. У меня просто есть папка с именем Test, и любой файл, начинающийся с Test_, становится тестом. Пока что это действительно легкий и легкий способ делать тесты.

В Java так много хороших библиотек ... Не в случае с C ++.

Для пользователей C ++ есть очень интересный инструмент из Kitware:

• CMake: сделать инструмент
• CDash: инструмент непрерывной интеграции

Kitware пишет C ++ коды для информатики.

Для личных проектов я использую библиотеку модульных тестов Boost (на платформе Desktop). Для непрерывной интеграции я использую Hudson:

• легко установить на Tomcat
• скрипты

Я буду второй TUT (шаблон модульного тестирования) ; он очень легкий и чрезвычайно гибкий, не говоря уже о том, что его очень легко настроить и использовать «из коробки» (один заголовок включает в себя, немного основного кода / кода настройки и 24 строки кода теста, после чего у вас есть модульное тестирование). Я объединил его с binfmtc (запускать программы на C ++ в виде скриптов) для быстрого создания прототипов / TDD / шаблонов обучения с большим успехом, включая разработку встроенного программного обеспечения. Благодаря возможности выводить в XML, он также прекрасно сочетался с Jenkins (CI) и Sonar в последующих моих проектах.