Используется ли BDD (Behavior Driven Development) в играх?

Некоторое время я читал о BDD - Behavior Driven Development, и считаю, что преобразовать функции в код очень просто и полезно. Пользователи BDD часто называют это TDD правильно.

BDD - это инструмент для разработки программного обеспечения, снаружи и внутри, от значения бизнеса (или значения игрового процесса) до кода.

Дэн Норт представляет BDD

Знаете ли вы какие-либо ресурсы о BDD и играх, кроме этого ?

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

Например, там, где я работаю, все наши названия модульных тестов являются «предложениями», как предлагает Дэн Норт в той статье, которую вы связали. Одного этого недостаточно, чтобы сказать, что мы используем BDD, конечно, но, может быть, это то, что вас действительно волнует?

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

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

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

Это? Может быть. Мое мнение таково, что оно очень плохо подходит для развлекательного программного обеспечения в целом, хотя оно может хорошо работать для библиотек низкого уровня.

РЕДАКТИРОВАТЬ: Вот некоторые оправдания для моего мнения.

Википедия определяет BDD как метод, который «поощряет сотрудничество между разработчиками, QA и нетехническими или бизнес-участниками в программном проекте». Это уже звучит как плохая идея, потому что игры отличаются от большинства программного обеспечения тем, что они не предназначены в качестве инструментов для удовлетворения конкретной потребности «нетехнического или делового участника», а представляют собой сплоченные работы, широко предназначенные для развлечения. Акцент делается на «желаемом поведении программного обеспечения», но игры редко имеют «желаемое поведение программного обеспечения», за исключением технического уровня. Есть определенная заслуга в проверке этой части кода, но не у конечного пользователя, потому что они никогда его не увидят.

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

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

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

def check_dice_roll_in_range():
    d = new Dice()
    assert(d.roll() between 1 and 6)

class Dice:
    def roll():
        return 4

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

Я бы не стал утверждать, что тестирование никогда не принесет никакой пользы: если объекты X и Y работают вместе, вы получите ожидаемый результат. Вопрос в том, используете ли вы наиболее эффективный способ проверки этого. Методы могут включать в себя формальную проверку, проверку кода, методы проверки вначале, методы проверки в последнюю очередь, традиционное тестирование черного ящика QA или просто использование кода, как ожидается, и наблюдение за результатами. Последние два варианта на удивление эффективны в большинстве случаев, потому что, несмотря на то, что они звучат так, как будто им не хватает строгости, большинство ошибок обнаруживаются в ходе обычного использования, и понять ошибку в ее естественном контексте иногда бывает проще, чем понять ее в искусственном тесте. упряжь. Кроме того,

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

(Надеюсь, это лучший ответ, даже если вы не согласны с моими утверждениями.)

Я думаю, что BDD подходит для любой среды. Как уже упоминалось, вы разрабатываете программное обеспечение, и в результате вы должны его протестировать. Мне нравится bdd для некоторых случайных семантик, упомянутых как имена тестов в качестве предложений. Мне также нравится группировать определенные тесты вместе, все еще будучи в состоянии проверить 1 класс.

Чтобы бороться с другими сообщениями здесь, я хотел бы отметить, что в более крупном проекте гораздо сложнее реорганизовать код без тестов. Если вы реорганизуете какой-то код, вы летите вслепую относительно того, все ли взорвется в сиянии славы или нет. Тесты помогут вам поймать вещи рано. Таким образом, вы пишете свой тест, проваливаете, код достаточно, чтобы пройти и продолжить. Когда вы проводите рефакторинг, вы должны делать то же самое, но вместо того, чтобы писать, вы пересматриваете тест. В большинстве случаев, когда вы запускаете тест, он проваливается, вы изменяете то, что, по вашему мнению, должно измениться, и ОСТАЕТСЯ неудачей. В этот момент вы понимаете, что какой-то другой фрагмент кода полностью зависит от этой функции / метода. Затем вы можете исправить свой тест и полученный код. Без такого покрытия кода вы бы часами спотыкались, пытаясь найти, где что-то сломалось,

Читайте о «Контрактах» в книге Прагматического Прогаммера. Тестирование помогает вам заключать контракты на код. Этот код выполняет X и ничего больше, чем X, и не ожидает, что он что-то сделает с Y или попытается адаптировать его для Z. Он обеспечивает чистоту кода и ожидает, что все будут не хуями и не испачкают базу кода.

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

От точки «как» это действительно зависит от вашей среды. Я пишу Java-игру сейчас и использую Robolectric. Вы всегда должны пытаться что-то «ожидать». Я слышал, что шпионы / mocks / stubs не так полезны, так как вам нужно иметь эквивалент с другой стороны, но иногда у вас нет выбора, особенно с API. Вы можете предположить, что другая сторона API не так уж и страшна, и обычно это ваш код, который отстой.

Если, например, вы тестируете движение. Что ж, вы ожидаете, когда нажмете «Вверх», что пользователь продвигается вперед на какое-то измерение.

Если, например, вы тестируете рендеринг графики ... хорошо, не проверяйте это слишком много, потому что вы действительно это делаете? Хороший тестовый фреймворк может решить эту часть для вас. Отражение не так уж тривиально, я бы сказал, для такого рода вещей. Вам может понадобиться проверить буферы и т. Д. Я просто проверю, что вы на самом деле делаете. Персонаж здесь, теперь он там после некоторого действия.

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

Я чувствую, что есть неправильное представление о том, что такое BDD. BDD не является техникой или процессом ТЕСТИРОВАНИЯ. BDD - это модель развития и процесс. Это выходит за рамки тестирования и выходит далеко за рамки программирования.

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