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


9

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

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

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

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


Это похоже на адаптацию TDD, и поэтому ссылка в значительной степени является дубликатом.
Коммунистическая утка

Поскольку BDD - это хорошо организованный процесс создания TDD, я хотел бы знать, использует ли его кто-то, и каков опыт.
MarcoTmp

Разве этот вопрос не отвечает на ваши вопросы?
Коммунистическая утка

Не совсем, потому что я до сих пор не знаю, как другие используют BDD в играх.
MarcoTmp

Я все еще чувствую, что это в основном TDD, выполненный в другом стиле.
Коммунистическая утка

Ответы:


14

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

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

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

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

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


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

1
-1. Спасибо за ваше мнение. Хотите ответить на вопрос?
Джесс Телфорд

+1, хороший ответ. @JoshPetrie Используете ли вы хотя бы иногда использование TDD или вы измеряете охват тестами? Просто интересно состояние тестирования разработчиков в игровой разработке.
Илья Иванов

1

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

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

Википедия определяет 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 или просто использование кода, как ожидается, и наблюдение за результатами. Последние два варианта на удивление эффективны в большинстве случаев, потому что, несмотря на то, что они звучат так, как будто им не хватает строгости, большинство ошибок обнаруживаются в ходе обычного использования, и понять ошибку в ее естественном контексте иногда бывает проще, чем понять ее в искусственном тесте. упряжь. Кроме того,

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

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


-1 от меня тоже; во всяком случае, BDD даже лучше подходит для игр, чем для других вещей. Еще более естественно указать поведение символа в ответ на ввод, чем указать поведение веб-службы в ответ на данное сообщение XML.
BlueRaja - Дэнни Пфлюгофт

1
Развлекательное программное обеспечение все еще остается программным, не так ли?
Пруссван

Хорошее разнообразие мнений экспертов очень ценно, ИМХО. У каждого человека есть ответный значок на их ответах, так что читатели могут придумать, как тяжело взвесить мнение, если взять их вместе с остальными, опубликованными для конкретного вопроса.
Ней

1
Я поддерживаю свою -1, и хотел бы ответить на некоторые из сказанного: collaboration between developers, QA and [users] [...] sounds like a bad idea - games rarely have 'desired software behaviour'- да, они делают: им должно быть весело. Лучший способ узнать, увлекательна ли ваша игра, - это послушать плейстеров. Разработчики часто ослеплены их созданием (или техническими трудностями) из-за того, что их игра неинтересна. У разработчиков, не являющихся разработчиками, таких проблем нет.
BlueRaja - Дэнни Пфлюгофт

2
Что касается тестирования: если вы пишете тесты именно так, то вы делаете это совершенно неправильно. Ex. чтобы проверить Dice, вы должны передать фиктивный объект Random и убедиться, что он Roll()возвращает правильные значения. Для тестирования симуляций (видеоигр) вы используете те же методы, что и для тестирования обычных приложений. Модульные тесты могут тестировать только юниты - поэтому вы правы, что «одних тестов никогда не бывает достаточно для обеспечения качества программного обеспечения» (именно поэтому QA все еще существует). Но это не значит, что они менее полезны для видеоигр.
BlueRaja - Дэнни Пфлюгофт

1

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

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

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

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

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

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

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

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


О, наконец, я заметил много людей, которые просто так ведут себя при кодировании игр / графики. Тестирование как бы предотвращает эффект "это просто работает". Гораздо сложнее ЗНАТЬ, как ваши уравнения будут влиять на вещи, чем просто копировать некоторый код и делать предположения.
Паррис

BDD - это не только тестирование, но и выход за рамки этого.
Даниэль

0

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.