Как я перемещаю репозиторий SVN в другой репозиторий SVN?

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

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

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

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

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

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