Является ли разработка через тестирование нормальным подходом в разработке игр?
Заменить {} на (( )):
tmpstart=0;
tmpend=4;
for (( i=$tmpstart; i<=$tmpend; i++ )) ; do
echo $i ;
done
Выход:
0
1
2
3
4
8 ответов
TDD стал любимым подходом разработчиков программного обеспечения, которые серьезно относятся к своей профессии. [ IEEE: TDD ] Преимущества этого подхода значительны, а затраты по сравнению с ним невелики. [ Три закона TDD ]
Нет программных доменов, для которых TDD не подходит или неэффективен. Однако есть домены, в которых это сложно. Игры, оказывается, один из них.
На самом деле, проблема не столько в играх, сколько в пользовательском интерфейсе. Причина, по которой пользовательский интерфейс является проблемой, заключается в том, что вы часто не знаете, как вы хотите, чтобы пользовательский интерфейс выглядел, пока не увидели его. Пользовательский интерфейс - это одна из тех вещей, с которыми вам придется возиться. Правильно понять это - глубоко итеративный процесс, который полон поворотов, тупиков и тупиков. Написание тестов сначала для пользовательского интерфейса, вероятно, будет и трудным, и расточительным.
Теперь, прежде чем все будут реветь и говорить: «Дядя Боб говорит:« Не делай TDD для UI »», позвольте мне сказать это. Тот факт, что трудно сделать чистый TDD для пользовательского интерфейса, не означает, что вы не можете сделать чистый TDD почти для всего остального. Большая часть игр связана с алгоритмом, и вы можете использовать TDD с этими алгоритмами на свое усмотрение. Это правда, особенно в играх, что некоторые из этих алгоритмов - это тот код, с которым вам нужно работать, как и в пользовательском интерфейсе, и поэтому они, вероятно, не поддаются тестированию вначале . Но есть много другого алгоритмического кода, который можно и нужно сначала написать для проверки.
Хитрость заключается в том, чтобы следовать принципу единой ответственности (SRP) и отделить те виды кода, с которыми вам придется поиграться, от тех видов, которые являются детерминированными. Не используйте в своем интерфейсе простые для тестирования алгоритмы. Не смешивайте ваш спекулятивный код с вашим не спекулятивным кодом. Храните вещи, которые меняются по причине А, отдельно от вещей, которые меняются по причине Б .
Кроме того, имейте это в виду: тот факт, что какой-то код трудно тестировать первым , не означает, что этот код трудно тестировать второго . После того, как вы поиграли, настроили код и заставили его работать так, как вам нравится, , затем вы можете написать тесты, демонстрирующие, что код работает так, как вы думаете. (Вы будете удивлены тем, сколько раз вы находите ошибки при этом.)
Проблема с написанием тестов «по факту» состоит в том, что часто код настолько связан, что трудно писать виды хирургических тестов, которые являются наиболее полезными. Поэтому, если вы пишете код, который сначала сложно протестировать , , вам следует соблюдать принцип инверсии зависимостей (DIP) и открывать / закрывать принцип (OCP) для того, чтобы код оставался достаточно разъединенным для проверки после факта.
Игры изнутри опубликовали статью , в которой обсуждается использование ими модульного тестирования, ограничения модульного тестирования в отношении игр, в частности, и сервер автоматического функционального тестирования, который они создали, чтобы помочь с этим.
Если вы ссылаетесь на практику написания и поддержки модульных тестов для каждого бита кода, я рискну предположить и заявить, что это не широко используется в игровой индустрии. Есть много причин для этого, но я могу думать о 3 очевидных:
- Культурные. Программисты консервативны, программисты игр вдвойне.
- Практические. TDD не очень хорошо подходит для проблемной области (слишком много движущихся частей).
- Crunchological. Там никогда не хватает времени.
Парадигма TDD лучше всего работает в прикладных областях, которые не очень состоят в состоянии, или, по крайней мере, где движущиеся части не все движутся одновременно, если говорить в разговорной речи.
TDD применимо к частям процесса разработки игры (базовые библиотеки и т. Д.), Но «тестирование» в этой области работы обычно означает выполнение автоматического пролета, случайного тестирования ключа, определения времени загрузки io, отслеживания fps-пиков. , убедившись, что игрок не может извиваться, вызывая зрительную нестабильность, и все в таком духе. Автомат также очень часто является гуманоидом.
TDD может быть полезным инструментом, но его статус как серебряной пули, которая должна быть повсеместно распространена при создании системы, довольно сомнителен. Разработка должна вестись не тестами, а разумом. RDD - это дерьмовая аббревиатура - она не приживется. ;)
Простой ответ «нет», TDD не является нормальным подходом в разработке игр. Некоторые люди указывают на Хаймуна и Нила Ллописа в качестве контрпримеров, но это большая индустрия, и они единственные, кого я знаю, кто полностью принял TDD. Я уверен, что есть и другие, но они единственные, о которых я знаю (и я работаю в этой отрасли уже 5 лет).
Я думаю, что многие из нас когда-то баловались юнит-тестированием, но по тем или иным причинам это не получилось. Судя по личному опыту, игровой студии сложно перейти на TDD. Обычно кодовая база хранится от проекта к проекту, и применение TDD к большой существующей кодовой базе является утомительным и в значительной степени неблагодарным. Я уверен, что в конечном итоге это окажется плодотворным, но заставить программистов игр купить его сложно.
У меня был некоторый успех в написании модульных тестов для низкоуровневого кода игрового движка, потому что этот код имеет очень мало зависимостей и легко инкапсулируется. Это всегда было проверкой после факта, хотя и не TDD. Код игры более высокого уровня обычно сложнее написать, потому что он имеет гораздо больше зависимостей и часто связан со сложными данными и состоянием. Взяв ИИ в качестве примера, для тестирования ИИ необходим некоторый контекст, то есть навигационная сетка и другие объекты в мире. Установка такого теста в изоляции может быть нетривиальной, особенно если задействованные системы не были предназначены для него.
Что более распространено в разработке игр, и у меня больше личного успеха, так это тест на дым. Вы часто будете видеть тестирование дыма, используемое в сочетании с непрерывной интеграцией, чтобы обеспечить различные виды обратной связи о поведении кода. Дымовое тестирование легче, потому что это можно сделать, просто подавая данные в игру и считывая информацию, без необходимости разбивать ваш код на крошечные тестируемые фрагменты. Снова взяв ИИ в качестве примера, вы можете указать игре загрузить уровень и предоставить скрипт, который загружает агента ИИ и дает ему команды. Затем вы просто определяете, выполняет ли агент эти команды. Это скорее тест на дым, чем на юнит-тест, потому что вы запускаете игру в целом и не тестируете систему искусственного интеллекта в изоляции.
По моему мнению, можно получить приличное тестовое покрытие, выполняя модульное тестирование кода низкого уровня, в то время как тестирование поведения высокого уровня в дыму. Я думаю (надеюсь), что другие студии также используют аналогичный подход.
Если мое мнение о TDD звучит несколько двусмысленно, то это потому, что так оно и есть. Я все еще немного об этом. Хотя я вижу некоторые преимущества (регрессионное тестирование, акцент на дизайне перед кодом), его применение и применение при работе с уже существующей кодовой базой похоже на рецепт головной боли.
@Rune Еще раз, пожалуйста, выделите «D», а не «T». На уровне модулей тесты - это инструмент мышления, который поможет вам понять, чего вы хотите, и повлияет на структуру кода. Конечно, на уровне устройства я обнаружил, что получаю более чистый и надежный код. Чем лучше качество частей, которые я помещаю в систему, тем лучше они сочетаются с меньшим количеством (но не без) ошибок.
Это совсем не то же самое, что серьезное тестирование, в котором нуждаются игры.
Большинство разработчиков игр не совсем согласны с современными методами разработки. К счастью.
Но модель развития, основанная на тестировании, подчеркивает, что сначала нужно сконцентрироваться на том, как что-то использовать, а затем уточнить, что оно делает. В общем, это хорошо, поскольку заставляет вас сконцентрироваться на том, как конкретная функция будет вписываться в то, что вы делаете (например, в игру).
Так что хорошие разработчики игр делают это естественно. Просто не явно.
TDD на самом деле нигде еще не является «нормальным» подходом, так как он все еще относительно новый и еще не получил универсального понимания или принятия. Это не значит, что некоторые магазины теперь не работают таким образом, но я все еще удивлен, когда слышу, что кто-то вообще использует его в этот момент.
Вероятно, основная причина заключается в том, что TDD предпочитают те, у кого есть языки, более способствующие ему. Но, кроме того, сами игры все равно плохо подходят для парадигмы.
В целом (и да, я имею в виду, вообще говоря, поэтому, пожалуйста, не забрасывайте меня контрпримерами), управляемый тестами дизайн лучше всего работает для систем, управляемых событиями, и не очень хорошо для систем в стиле моделирования. Вы по-прежнему можете использовать тесты на ваших низкоуровневых компонентах в играх, будь то тестовое или простое модульное тестирование, но для задач более высокого уровня редко бывает какое-либо дискретное событие, которое вы можете смоделировать с детерминированными результатами.
Например, веб-приложение обычно имеет очень четкие входные данные (HTTP-запрос), изменяет очень небольшое количество состояний (например, записи в базе данных) и генерирует в значительной степени детерминированный вывод (например, HTML-страница) , Их можно легко проверить на достоверность, а поскольку создание входных данных просто, создание тестов тривиально.
Однако в играх может быть сложно смоделировать ввод (особенно если он должен произойти в определенный момент ... подумайте о прохождении экранов загрузки, экранов меню и т. Д.), Количество изменяемого состояния может быть большим (например, если у вас физическая система или сложный реактивный ИИ), и выходной сигнал редко бывает детерминированным (основным виновником здесь является использование случайных чисел, хотя такие вещи, как потеря точности с плавающей запятой, являются другими, как могут быть спецификации оборудования или доступны Процессорное время или производительность фонового потока и т. Д.).
Чтобы выполнить TDD, вам нужно точно знать, что вы ожидаете увидеть в определенном событии, и иметь точный способ его измерения, и обе эти проблемы являются сложными с симуляциями, которые избегают дискретных событий, преднамеренно включают случайные факторы, действуют по-разному на разных машинах, и имеют аналоговые выходы, такие как графика и аудио.
Кроме того, есть одна серьезная практическая проблема - время запуска процесса. Многие из вещей, которые вы захотите протестировать, требуют загрузки больших объемов данных, и если вы копируете данные, вы на самом деле не тестируете алгоритм. Имея это в виду, быстро становится непрактичным иметь какие-либо испытательные леса, которые просто выполняют отдельные задачи. Вы можете запускать тесты на веб-сервере без необходимости каждый раз отключать веб-сервер - это редко возможно для игр, если вы не проводите тестирование на встроенном языке сценариев (что разумно и действительно имеет место в отрасли).
Например, вы хотите добавить объемный рендеринг теней в свои игровые здания. Таким образом, вам нужно написать тест, который запускает все необходимые подсистемы (например, рендерер, игра, загрузчики ресурсов), загружает здания (включая сетку, материалы / текстуры), загружает камеру, устанавливает камеру в укажите на здание, включите тени, визуализируйте сцену, а затем каким-то образом решите, действительно ли тени появляются в буфере кадров. Это менее чем практично. В действительности у вас уже есть все эти строительные леса в виде вашей игры, и вы просто запускаете их для проведения визуального теста в дополнение к любым утверждениям в самом коде.