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

Ответ 1

TDD стал предпочтительным подходом разработчиков программного обеспечения, которые серьезно относятся к своей профессии. [IEEE: TDD] Преимущества этого подхода значительны, а затраты низки для сравнения. [Три закона TDD]

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

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

Теперь, прежде чем все ревут и говорят: "Дядя Боб говорит:" Не делай TDD для UI ", позвольте мне сказать это. Тот факт, что трудно делать чистый TDD для пользовательского интерфейса, не означает, что вы не можете делать чистую TDD практически для всего остального. Большая часть игр - это алгоритм, и вы можете использовать TDD с этими алгоритмами в своем сердце. Это правда, особенно в играх, что некоторые из этих алгоритмов - это тот код, с которым вам приходится сталкиваться, как пользовательский интерфейс, и, вероятно, не поддаются проверке. Но есть много других алгоритмических кодов, которые могут и должны быть написаны сначала.

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

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

Проблема с письменными тестами "после факта" заключается в том, что часто код настолько связан, что трудно написать те хирургические тесты, которые наиболее полезны. Поэтому, если вы пишете код, который трудно проверить в первую очередь, вы должны позаботиться о принципе инверсии зависимостей (DIP), и принцип open/closed (OCP), чтобы код был достаточно развязан, чтобы проверить его после факта.

Ответ 2

Простой ответ "нет", TDD не является нормальным подходом в разработке игр. Некоторые люди будут указывать на Highmoon и Neil Llopis в качестве контр-примеров, но это большая индустрия, и они являются единственными, кого я знаю, кто полностью охватил TDD. Я уверен, что есть другие, но они единственные, кого я знаю (и я был в отрасли уже 5 лет).

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

У меня был некоторый успех в написании модульных тестов для низкоуровневого кода игрового движка, потому что этот код имеет очень мало зависимостей и легко инкапсулирован. Это всегда проверялось после факта, хотя и не TDD. Более высокий уровень игрового кода, как правило, сложнее писать тесты, потому что он имеет гораздо больше зависимостей и часто связан со сложными данными и состоянием. Принимая ИИ в качестве примера, для проверки ИИ требуется какой-то контекст, то есть навигационная сетка и другие объекты в мире. Настройка такого рода тестов по отдельности может быть нетривиальной, особенно если задействованные системы не предназначены для этого.

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

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

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

Ответ 3

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

Ответ 4

Если вы имеете в виду практику написания и поддержки модульных тестов для каждого кода, я бы рискнул предположить и заявить, что это не широко используется в игровой индустрии. Для этого есть много причин, но я могу думать о 3 очевидных:

• Культурные. Программисты консервативны, программисты игры вдвойне.
• Практичный. TDD не очень хорошо подходит для проблемной области (слишком много движущихся частей).
• Crunchological. Там никогда не бывает достаточно времени.

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

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

TDD может быть полезным инструментом, но его статус серебряной пули, которая должна быть вездесущей при создании системы, довольно сомнительна. Разработка не должна определяться испытаниями, но по разуму. RDD - это дерьмовая аббревиатура, хотя - она ​​не поймает.;)

Ответ 5

Вероятно, основная причина заключается в том, что TDD предпочтительнее тех, у которых есть языки, более благоприятные для него. Но кроме того, игры сами по себе плохо подходят для парадигмы.

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

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

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

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

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

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

Ответ 6

Большинство разработчиков игр не совсем с точки зрения современных методов разработки. К счастью.

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

Так хорошие разработчики игр делают это естественно. Просто не явным образом.

Ответ 7

@Rune Еще раз подчеркните "D", а не "T". На уровне единицы тесты - это инструмент мышления, который поможет вам понять, что вы хотите, и управлять дизайном кода. Разумеется, на уровне единицы я нахожу, что в итоге получается более чистый, более надежный код. Чем лучше качество деталей, которые я вкладываю в систему, тем лучше они сочетаются с меньшими (но не отсутствующими) ошибками.

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

Ответ 8

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