Тестування блоку ігрового проекту C # / XNA

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

У світі бізнесу (на стеку Microsft web-dev) ASP.NET MVC стає дуже популярним через простоту тестування одиниць способу роботи інтерфейсу.

Мені цікаво, які шаблони дизайну (MVC, MVP, MVVM тощо) можна використати для написання гри, в якій вся логіка гри легко перевіряється одиницею. Це можливо чи можливо? Я витрачаю свій час, чи краще робити повні збірки, а потім виконувати тести типу "інтеграція" замість одиничних тестів?

Зразок коду був би чудовим, але корисна також і запис.

(Я намагався додати тег одиничного тестування, але повтор не потрібен ...)

— Нейт
джерело

Ось хороша стаття, яку я знайшов, що описує архітектуру для відокремлення функціональності, щоб зробити її не тільки легко використаною, але й потенційно набагато простішою для тестування одиниць:

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

У деяких іграх виграє MVC-зразок. На розум приходять настільні ігри, такі як шахи та карткові ігри. Однак у більшості випадків це масовий перебір.

Особисто я вважаю, що достатньо лише тестувати тести, які мають алгоритмічну природу. Речі, від яких ви будете залежати, "просто працюватимуть", коли ви пишете геймплей-код, і підступно важко буде відслідковувати проблеми, якщо вони не виникають. Такі речі, як тести на перехрестя або мережевий код.

(Речі, які в ідеалі будуть вбудовані в сторонні рамки, тому вам не доведеться їх писати чи перевіряти!)

Один з методів, який я люблю використовувати для тестування речей, пов’язаних з іграми, - це те, що я називаю "тестуванням наочної одиниці". Основна концепція - це проста лінійна передача біта коду, про який йдеться (скажімо, наприклад, функція перетину), а також деякі основні завдання клавіші чи миші для маніпулювання входами. Ніхто не сказав, що одиничні тести повинні бути автоматизовані - вони просто повинні розбити речі на окремі одиниці та перевірити їх.

— Ендрю Рассел
джерело

Гарна відповідь. Я також хотів опублікувати саме цю статтю. Компонентні системи ігрових об'єктів - це чудовий спосіб відокремити логіку та мати можливість їх індивідуально перевірити. Однак жоден одиничний тест не може зробити це складні взаємодії кількох шляхів логіки гри, що взаємодіють у реальному часі у випадковій послідовності. Це було б як спробувати перевірити прогноз погоди. :)

— LearnCocos2D

Так, я також роблю маленькі тестери, які виділяють певні біти функціональності. Я переконуюсь, які зміни я вносимо в API та ін. Я завжди впевнений, що вони все ще працюють. Набагато простіше повторно використовувати функціональність у наступному проекті.

— Iain

Так, гарна відповідь, і мені подобається посилання. І я погодився з усім до останнього рядка: "Ніхто не сказав, що одиничні тести повинні бути автоматизовані". :) Доведеться , можливо, ні - але все, що я прочитав, означає (або сказано прямо), що тести для одиниць повинні бути автоматизованими , до того моменту, коли ви натискаєте лише одну кнопку, щоб запустити всі ваші тести. В іншому випадку, чим більше роботи, пов’язаної із запуском тестів, тим менше шансів на те, що ви будете запускати їх досить часто. Зрозуміло, якщо ви говорите про дисплей- код, його можна зробити набагато складніше, якщо це можливо.

— Циклоп

Майже чотири роки тому, і я вважаю, що я розробив краще розуміння того, чому "візуальний тест одиниці" працює так добре: Одиничні тести - це інструмент розробки. Автоматизований тест типового апарату може сказати вам , що що - то буде порушено. Але візуальний тест блоку може дати вам вивчити дуже складні алгоритми та допомогти швидко визначити, чому щось порушено (особливо в поєднанні з редагуванням живого коду). Часто візуальний тест може виявити проблеми, на які в іншому випадку доведеться передбачити тестування з кодом, або проблеми, на яких немає «правильної» відповіді (наприклад: налаштування).

— Ендрю Рассел

І думка про те, що одиничні тести потрібно виконувати "досить часто" (як: завжди, в автоматизованому вигляді) є хибною. Код, який не змінюється, очевидно, не потрібно повторно перевіряти. І коли код буде модифікуються, розробник робить модифікацію повинен робити так , в той час , використовуючи відповідні доступні тести (візуальна, на основі коди або іншим чином ). Очевидно, існує код з певним профілем ризику, де автоматизований тест є вартістю часу. Але такі сценарії особливо рідкісні в розробці гри.

— Ендрю Рассел