Який блок тестування для ігор на основі с ++? [зачинено]

Яка комбінація засобів тестування, на вашу думку, найкраща? З огляду на обрану рамку / бібліотеку ви можете врахувати:

• придатність для TDD
• простота використання / продуктивність
• поводження з макетними предметами
• налаштування з постійною інтеграцією
• повідомлення про помилки

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

Я виявив, що UnitTest ++ дуже легко працювати. Мені все ж доведеться спробувати разом з ним amop , який згадувався як хороший супутник UnitTest ++ для макетних функцій об'єкта. Інакше Google Mock - популярний вибір. Крім того, ви можете прочитати на UnitTest ++ та Mock Objects .

UnitTest ++ можна налаштувати за допомогою підходу безперервної інтеграції, наприклад, з Хадсоном

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

Ще один голос за UnitTest ++ . Дуже легко інтегрувати, складений для нашої цільової вбудованої платформи дуже легко, просто та легко у використанні. Ми також інтегрували його з Хадсоном. Ми подивилися на 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 . Він має всі найкращі характеристики останніх тестових рамок блоку, зберігаючи все це в мінімальному інтерфейсі, потоковому потоці.

Наступним у моєму списку є Boost Test . Тест Google тест трохи сучасніший, ніж Boost.Test, але тест Boost зробив дивовижну роботу, додавши нові функції та вириваючи стійку парадигму 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 ++ коди для Computer Science.

Для особистих проектів я використовую тестову бібліотеку блоку Boost (на платформі Desktop). Для постійної інтеграції я використовую Хадсон:

• проста установка на Tomcat
• сценарій

Я відправлю рамку TUT (Тестовий блок тесту) ; це надзвичайно легкий та надзвичайно гнучкий, не кажучи вже про дуже простий у налаштуванні та використанні з коробки (один заголовок включає, трохи основного / коду настройки та 24 рядки тестового коду, пізніше у вас є одиничний тест). Я поєднав його з binfmtc (запускайте програми C ++ як сценарії) для швидкого прототипування / TDD / шаблонів навчання з великим успіхом, включаючи розробку вбудованого програмного забезпечення. Завдяки тому, що він мав змогу виводити XML, він також прекрасно співпрацював з Дженкінсом (CI) та Sonar щодо наступних моїх проектів.