Как спроектировать игровое программное обеспечение так, чтобы его можно было легко тестировать?

Практично ли использовать среду тестирования, такую ​​как JUnit, в ситуации разработки игры? Какими конструктивными соображениями вы можете следовать, чтобы сделать вашу игру более тестируемой? Какие части игры можно / нужно тестировать и какие части следует / нужно оставить для тестирования человеком?

Например, если игровой цикл заключен в одну функцию, кажется, что это будет ужасно сложно проверить. Мне нравится рефакторинг функции «обновления», которая занимает дельту времени и продвигает игровую логику; это позволяет использовать некоторые интересные трюки, такие как возможность замедлить игру, подкармливая ее фальшивыми медленными дельтами времени.

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

Для меня есть только две вещи, которые я не тестирую в рамках модульного тестирования:

Во-первых, я не проверяю визуальные элементы и то, как все выглядит. Я проверяю это, и объект будет в нужном месте после обновления, что камера выберет объект за его пределами, что преобразования (по крайней мере, те, которые выполняются вне шейдеров) выполняются должным образом перед передачей графическому движку. , но как только он попадает в графическую систему, я рисую линию. Мне не нравится пытаться издеваться над такими вещами, как DirectX.

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

Ноэль Ллопис покрыл юнит-тестирование в той степени, в которой, я полагаю, вы ищете:

• http://gamesfromwithin.com/stepping-through-the-looking-glass-test-driven-game-development-part-1
• http://gamesfromwithin.com/stepping-through-the-looking-glass-test-driven-game-development-part-2
• http://gamesfromwithin.com/stepping-through-the-looking-glass-test-driven-game-development-part-3
• http://gamesfromwithin.com/backwards-is-forward-making-better-games-with-test-driven-development
• (у него также есть много других статей о TDD)

Что касается тестирования всего игрового цикла, есть еще один метод предотвращения функциональных регрессий в вашем коде. Идея состоит в том, чтобы ваша игра играла сама через систему воспроизведения (то есть сначала записывает входные данные игрока, а затем воспроизводит их во время другого прогона). Во время воспроизведения вы создаете снимок состояния каждого объекта для каждого кадра. Эту коллекцию состояний можно затем назвать «золотым образом». При рефакторинге вашего кода вы снова запускаете воспроизведение и сравниваете состояние каждого кадра с золотым состоянием изображения. Если он отличается, тест не пройден.

Хотя преимущества этого метода очевидны, есть несколько вещей, с которыми нужно быть осторожным:

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

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

Аналогичным образом, другие части игры, которые зависят от сущностей, должны полагаться только на подмножество компонентов, чтобы функционировать. На практике это означает, что вы обычно можете смоделировать несколько поддельных компонентов, чтобы облегчить тестирование этих областей, или вы можете просто составить частичные объекты для целей тестирования. например, вы пропускаете компоненты рендеринга и ввода, потому что они не нужны для проверки физики.

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

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

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

(С отличным мониторингом и продуктом, работающим как услуга, действительно возможно провести некоторое «тестирование» на клиенте, но вам нужна сложная система, которая быстро обнаруживает ошибки и откатывает ответственные за изменения. Скорее всего, это слишком много для небольшая команда разработчиков.)

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