Модульное тестирование игрового проекта на C # / XNA

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

В деловом мире (в стеке Web-разработчика Microsft) ASP.NET MVC становится по-настоящему популярным благодаря простоте модульного тестирования работы интерфейса.

Мне интересно, какие шаблоны проектирования (MVC, MVP, MVVM и т. Д.) Можно использовать для написания игры, в которой вся игровая логика легко тестируется юнитами. Это возможно или возможно? Я трачу свое время, лучше ли делать полные сборки, а затем запускать тесты типа "интеграция" вместо юнит-тестов?

Пример кода был бы хорош, но рецензия также полезна.

(Я пытался добавить тег юнит-тестирования, но у меня нет нужного представителя ...)

— Nate
источник

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

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

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

Лично я считаю, что достаточно только модульного тестирования вещей, которые имеют алгоритмический характер. Вещи, от которых вы будете зависеть, «просто работают», когда пишете код геймплея, и могут быть коварно трудными для выявления проблем, если они этого не делают. Такие вещи, как тесты пересечения или сетевой код.

(Вещи, которые в идеале будут встроены в сторонние фреймворки, так что вам не придется их писать или тестировать!)

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

— Эндрю Рассел
источник

Хороший ответ. Я также хотел опубликовать именно эту статью. Компонентные системы Game Object - отличный способ отделить логику и быть в состоянии протестировать их по отдельности. Однако ни один модульный тест не может выполнять сложные взаимодействия множества путей игровой логики, взаимодействующих в реальном времени в случайной последовательности. Это было бы все равно что пытаться тестировать прогноз погоды. :)

— LearnCocos2D

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

— Иан

Да, хороший ответ, и мне нравится ссылка. И я согласился со всем до последней строки: «Никто не говорил, что модульные тесты должны быть автоматизированы». :) Have до, может быть , нет - но все , что я читал , следует (или прямо говорит) , что модульные тесты должны быть автоматизированы , до момента , когда вы только нажать одну кнопку , чтобы запустить все тесты. В противном случае, чем больше работы потребуется для выполнения тестов, тем меньше вероятность, что вы будете запускать их достаточно часто. Конечно, если вы говорите о коде дисплея , его может быть гораздо сложнее, если даже возможно.

— Циклоп

Прошло почти четыре года, и я чувствую, что у меня появилось лучшее понимание того, почему «визуальный модульный тест» работает так хорошо: модульные тесты являются инструментом разработки. Автоматизированный тест типичного аппарата может сказать вам , что что - то будет нарушено. Но визуальный модульный тест может позволить вам изучить очень сложные алгоритмы и помочь вам быстро определить, почему что-то не работает (особенно в сочетании с редактированием живого кода). Часто визуальный тест может выявить проблемы, которые в противном случае вам придется ожидать при тестировании с помощью кода, или проблемы, в которых нет «правильного» ответа (например, настройка).

— Эндрю Рассел

И идея о том, что юнит-тесты нужно запускать «достаточно часто» (как всегда, автоматически), является ложной. Код, который не изменяется, очевидно, не нуждается в повторном тестировании. И когда код будет модифицируются, разработчик делает модификацию должен делать так , в то время , используя соответствующие доступные тесты (визуальная, на основе коды или иным образом ). Очевидно, существует код с определенным профилем риска, в котором автоматизированное тестирование является оправданным вложением времени. Но такие сценарии особенно редки в разработке игр.

— Эндрю Рассел