Является ли модульное тестирование жизнеспособным в игровом программировании?

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

Рассмотрим простое действие, подобное playerJump(height). Я хотел бы иметь набор тестов, который проверяет большое количество случаев, чтобы убедиться, что прыжки всегда работают так, как ожидалось. Однако эта функция, скорее всего, не вернет значения и будет иметь побочный эффект, player.velocity.y = -height и checkCollisions(player). Я не могу придумать ясный unit test, чтобы построить вокруг этого.

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

Update:

Игры изнутри содержат ряд подробных статей об использовании Test Driven Development в играх. Я настоятельно рекомендую их всем, кто интересуется этой темой. Вот первая статья:

http://gamesfromwithin.com/stepping-through-the-looking-glass-test-driven-game-development-part-1

Ответ 1

Часто код не разбивается на отдельные единицы.

Это просто плохой дизайн. Код не разбивается ни на что. Вы, разработчик, должны наложить структуру кода, чтобы вы могли продемонстрировать, что она действительно работает.

Однако эта функция, скорее всего, не вернет значение...

Так?

... и имеют побочный эффект, player.velocity.y = -height и checkCollisions(player).

Затем проверьте это.

Я не могу придумать ясный unit test для построения вокруг этого.

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

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

Но ваша спецификация поведения была идеальной. Просто проверьте, что вы описали.

Ответ 2

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

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

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

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

Кроме того, игры требуют много испытаний геймплея (где настоящие пользователи просто играют в нее). Это найдет странные случаи, которые вы не рассматривали с помощью автоматических тестов, но, что более важно, ответ будет отвечать на вопрос, что автоматическое тестирование никогда не ответит: "Это правильно"? Это весело"? Это тесты, которые может проводить только человек.

Ответ 3

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

Ответ 4

Мой опыт работы с блоком и автоматизация тестирования во время разработки Crysis 2 можно найти здесь: http://yetanothergameprogrammingblog.blogspot.com/2010/06/aaa-automated-testing.html Надеюсь, что это поможет.

Резюме:

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

Ответ 5

Единичное тестирование просто не волнует, как "с точки зрения состояния" ваш блок. У вас есть более или менее автономный фрагмент кода, и если его вектор ввода и вывода огромен, тогда тестирование сложно. Независимо от того, установлены ли эти векторы как состояния до и после выполнения, это немного изменяет процесс тестирования. Если вы хотите сообщить нам, однако, что вы не можете придумать правильный способ определения тестовых примеров, например, в самых простых модульных тестах/документах по тестированию, то есть испытуемый объект является чем-то вроде "f (x) = y", затем да, я согласен, вам будет трудно доказать, что несколько (x [100], y [99]) векторов, которые человеческий тростник имеет с достаточным покрытием (численные значения!). Попробуйте сформулировать интегративные свойства и инварианты и перейти на автоматическое тестирование.

Ответ 6

Посмотрите PEX для автоматического создания unit test. Он будет генерировать модульные тесты для всех возможных вариантов ввода, которые помогут вам протестировать множество возможных комбинаций.

Ответ 7

Многие программисты используют Архитектура системы Entity-component-system. Они делают это, потому что это облегчает изменение поведения в игровых объектах. Но, как это бывает, это также облегчает unit test ваш код.