Comments 13
А не смотрели другие популярные движки, например godot, насколько лучше там с тестами?
Нет, не смотрел ни в Unreal ни в Godot. Но от движка может зависеть только пункт Архитектура Unity враждебна к TDD,А все остальное остается актуальным для геймдев вцелом
Я про этот пункт и спрашивал. Более того утверждение в заголовке статьи делается о gamedev в целом, а не об юнити. Что если в других движках TDD легко интегрируется а проблема только в unity?
В любом же случае вам нужно геймплей итерировать, и написанные вами тесты будут быстро удалены из проекта, поэтому это действительно может не зависить от движка.
Оправдано писать тесты (даже для Unity, ибо монобехи стараются не использовать в кор логике, только как вьюшки) если вам нужно написать достаточно сложную систему, или же обобщенный функционал, который врят ли будет меняться. По опыту выходит так, что на клиенте тестов делается сравнимо мало, чем на бекенде. Поэтому как уже говорил автор, это не чистый TDD подход, а скорее ситуативный гибрид
Хотелось бы уточнить про SDK - как бы их ловчее автоматически тестировать? Например, мобильный платеж. Ну, что игрок еще может кристалликов купить в мобильной игре, деньги со счета спишутся, кристаллики сервер начислил, клиент показал, и все хорошо.
Почему никто не использует Test-Driven Development в геймдев?
Странное утверждение конечно. TDD не работает там, где нет чётких требований. Поэтому при написании собственного движка/фреймворка можно использовать TDD. Даже в "нетестируемой тройке" есть некоторый набор функциональности, который вполне можно тестировать - какие-нибудь классы векторов, конвертация юнитов и тп. Визуальный фидбэк да, сложно анализировать, хотя и тут есть некоторые варианты. То же UI тестирование вполне себе реальная вещь. Хотя писать подобные тесты ни разу не проще чем писать функциональность для тестирования.
Если речь идёт конкретно за разработку игр - там обычно есть диздок с общим видом функционала игры, а детали уточняются по мере разработки и последующих плейтестов - написать автотест на то чтобы какой-нибудь платформинг или стрельба ощущались хорошо нереально, т.к. это дизайнерский нюанс, а не функиональный. Поэтому разработка геймплея или визуального фидбэка не тестируема.
Не вижу противоречий.
В пункте "Где TDD в Unity всё же работает" как раз описан случай с математическими утилитами "Математические утилиты: расчёт траектории, интерполяция, патфайндинг". Кастомный движок думаю можно подвести к этому пункту
Я и не утверждаю, что тестировать UI нельзя, я сам делал тесты UI на проекте. Но через TDD сделать UI не получится
Никто в геймдеве - подразумевает что ни один человек в геймдеве не использует TDD. Примеры с фреймворками я уже привел. Метафункционал конкретной игры туда же. Получается, либо мы не считаем эти сферы геймдевом, либо начинаем считать вас за редиску.
Второй нюанс - не очень понятно что подразумевается под "сделать UI". Обычно UI дизайнится в условном фотошопе, пилится на элементы и собирается при помощи кода на экране. Всегда можно прикрутить возможность ткнуть в элемент на экране и сделать тест на прохождения некоторого пути по рабочим элементам - переходы между экранами обычно к этому моменту уже известны, найти интерактивный элемент на экране из кода тоже не проблема даже на резиновых layout, так что ткнуть по элементу виртуальной мышью - тоже не проблема. Единственная причина почему это непопулярно - бОльшие трудозатраты при меньшем выхлопе, если сравнивать с тестированием стабильности навигации на сайте в браузере. Это совершенно точно можно начинать с теста, просто польза от этого не слишком высокая, особенно если того UI кот наплакал.
Мне статья не понравилась, поскольку в ней мало практической составляющей, только общие слова про тесты, да еще и в отрыве от бизнеса все это описано. Как будто статью можно ужать в абзац "TDD это плохо в юнити, потому что ... вывод;" и статья не потеряет смысла.
Конкретнее если, в статье ни слова про архитектуру, которая
а) действительно позволит писать тестируемый код не в ущерб производительности команды
б) не мешает нетехнарям гд и прочим талантливым ребятам, которые приносят студии миллионы, быстро менять что то в проекте без программистов
с) не увеличит порог входа для программистов/гд/итд с рынка, чтобы я мог нанять мидла среднего и он сделал новую фичу после онборда без вопросов, как тут тестами че покрыть и зачем
Также я не понял второй тейк в разделе почему тдд не работает в юнити. Разве я не могу в рамках определенной, устоявшейся архитектуры использовать tdd подход? Почему это не трушное тдд?? "Я пишу тест под фичу, которой нет, но если уже есть архитектура - это не тдд" получается.
И еще у меня сильные сомнения про генерацию тестов нейронкой, исключительно имхо. Тесты это апофеоз инженерного мышления, что у нейронок пока, к сожалению, туго идет, и, по моему опыту, агенты(я тестил на топовых в кодексе, клод коде, гемини) генерируют очень посредственные тесты, тесты ради тестов, которые человек не напишет и не прочитает, а на проде всё равно будет баг. Я пробовал генерить тесты для серверной меты, для ui и для некоторой части геймплейной логики, написанной на ецс. И вот что касается за несколько минут сгенерить тесты - не верю, покажите как получить результат за пару минут.
Резюмируя, было бы здорово увидеть конкретные примеры во второй части статьи, что и как у вас обложено тестами, как выглядел первый тест в тдд и как писалось перечисленное по нему, и как в общем пишется код для перечисленного в разделе "где тдд всё же работает" в рампках тдд, а также зрелую фичу зафиксированную тетсами - интересно какое покрытие и как все устроен, чтобы это работало и несло какой то велью.
Почему никто не использует Test-Driven Development в геймдев?