Чи BDD (поведінка керована розвитком) використовується в іграх?


9

Я деякий час читав про BDD - розвиток, керований поведінкою, і конвертую функції в код дуже просто і корисно. Користувачі BDD часто називають це TDD зроблено правильно.

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

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

Чи знаєте ви будь-які ресурси про BDD та ігри, крім цього ?


Це схоже на адаптацію TDD, і як таке, що посилання є майже дублікатом.
Качка комуністична

Оскільки BDD - це добре організований процес робити TDD, я хотів би знати, чи хтось ним користується, і який досвід.
MarcoTmp

Чи не відповідає це питання на ваші запитання?
Качка комуністична

Не дуже, бо я досі не знаю, як інші використовують BDD в іграх.
MarcoTmp

Я все ще відчуваю, що в основному TDD виконується в іншому стилі.
Качка комуністична

Відповіді:


14

Напевно, можна з упевненістю сказати, що BDD, як TDD, або (вставте сюди модну парадигму-мовлення) використовується деякими розробниками ігр десь, але вони, мабуть, не знають, що вони є, і не обов'язково зможуть визначити, що BDD насправді означає . Питання справді в тому, наскільки вони ним користуються і скільки вони повинні використовувати, щоб він мав значення для вас?

Наприклад, там, де я працюю, усі назви наших тестових одиниць - це "пропозиції", як пропонує Ден Норт у тій статті, яку ви пов'язали. Це одне недостатньо, щоб сказати, що ми використовуємо BDD, звичайно, але, можливо, це те, що ти насправді хвилюєш?

На мою думку, увага не повинна приділятися тому, яке мовленнєве слово ви застосовуєте в студії, а саме тому, які методи продуктивності та розвитку ви використовуєте загалом. Я вважаю, що найпродуктивніші команди змішують та узгоджують методи з різних "модних парадигм", а не вчиняють, догматично, будь-яку частину жорсткої доктрини, за якою деякі дослідження в Інтернеті містять одну конкретну парадигму-мозку.

Я це бачу найчастіше з тенденцією Agile: команди, які ідентифікують себе як "роблячи Agile", як правило, більш негнучкі (іронічно) щодо процесу, ніж команди, які органічно включають в себе біти Agile, які мають для них сенс. На моєму досвіді колишні команди майже завжди виявляються менш продуктивними.

Команда розробників складається з людей, які не є взаємозамінними гвинтиками в машині. Вони діють унікально як особистості і як унікальне поєднання самих себе. Шлях до ефективного розвитку - не зводити своїх людей у ​​форму {BDD, Agile, WeverIsNext}, а постійно переоцінювати, як команда прогресує та усуває недоліки в процесі, замінюючи зламані технології та підсилюючи речі, які є робочий. Коротше кажучи, зосередитись на доставці заголовка, а не на "бути спритним (чи будь-яким іншим").


Слід, звичайно, зазначити, що все, що я маю, є анекдотичними свідченнями тут, моїх коментарів щодо зв'язку між чітко прихильним процесом догматики та продуктивністю. Це просто мій досвід, а не наукове дослідження.

1
-1. Дякую за вашу думку Хочете відповісти на питання?
Джесс Телфорд

+1, приємна відповідь. @JoshPetrie Чи використовуєте ви принаймні іноді TDD або вимірюєте покриття тестами? Просто цікавий стан тестування розробників в ігрових розробниках.
Ілля Іванов

1

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

EDIT: Ось якесь обґрунтування моєї думки.

Вікіпедія визначає BDD як техніку, яка "заохочує співпрацю між розробниками, QA та нетехнічними або діловими учасниками програмного проекту". Це вже звучить як погана ідея, оскільки ігри відрізняються від більшості програмного забезпечення тим, що вони не розроблені як інструменти для задоволення конкретної потреби у «нетехнічному або бізнес-учаснику», а є згуртованими творами, розробленими в цілому для розваги. Є акцент на "бажаній поведінці програмного забезпечення", але ігри рідко мають "бажану поведінку програмного забезпечення", крім технічного рівня. Однозначно є заслуга в тому, щоб перевірити цю частину коду, але не з кінцевим користувачем, оскільки вони його ніколи не побачать.

Але припустимо, що ви хочете викинути цю людину з зацікавленими сторонами і просто використовувати BDD для забезпечення контрактів між різними модулями коду, які, наскільки я бачу, не сильно відрізняються від звичайних тестових розробок, які я також вважаю погано- підходить для ігор з наступної причини.

Тести корисні для перевірки того, що дискретні події сталися, коли очікували. Це добре працює в програмуванні на основі подій, тобто. у більшості програмного забезпечення, де виконується дія, генерується деякий вихід, а потім ви просто переконайтеся, що дія та результат збігаються. Однак ігрове програмне забезпечення, як правило, є симуляцією, коли дія має не дискретний результат, а постійну зміну світової держави. Якщо мій прихований програвач шумить, я, можливо, захочу перевірити, чи AI полює на мене. Отже, я можу створити тест, щоб переконатися, що ШІ знаходиться у «мисливському» стані після створення шуму, і це чудово. Але як я знаю, що полювання навіть працює? Ви не можете це перевірити миттєво - ви можете спостерігати це лише впродовж часу.

Крім того, тестовий підхід може створити помилкове почуття безпеки та спонукати людей вважати, що код кращий, ніж є насправді.

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 - Danny Pflughoeft

1
Програмне забезпечення для розваг все ще є програмним забезпеченням, чи не так?
prusswan

Хороша різноманітність думок експертів є дуже цінною, ІМХО. Кожна людина має знак відповіді на свої відповіді, тому читачі можуть придумати, наскільки важко зважити думку, якщо їх прийняти спільно з рештою, розміщеною з певного питання.
Нейт

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

2
Щодо тестування: якщо саме так ви пишете тести, то ви робите це зовсім неправильно. Вих. щоб перевірити Dice, ви переходите в макетний Random об'єкт і переконайтеся, що Roll()повертає правильні значення. Для тестування симуляцій (відеоігор) ви використовуєте абсолютно ті самі методи, що і для тестування звичайних програм. Тестові одиниці можуть проводити лише тестові одиниці, тому ви впевнені, що "лише тести ніколи не є достатніми для забезпечення якості програмного забезпечення" (саме тому QA все ще існує). Але це не означає, що вони менш корисні для відеоігор.
BlueRaja - Danny Pflughoeft

1

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

Для боротьби з іншими повідомленнями тут я хочу зазначити, що для більшого проекту набагато складніше рефакторний код без тестів. Якщо ви відновлюєте якийсь код, ви сліпаєте, чи все вибухне в очах слави чи ні. Тести допоможуть вам зловити речі рано. Таким чином, ви пишете свій тест, провал, код достатньо, щоб пройти і продовжити. Коли ви рефактор, ви повинні зробити те саме, але замість того, щоб писати, ви переглядаєте тест. У більшості випадків ви запускаєте тест, він не вдасться, ви змінюєте те, що, на вашу думку, повинно змінитись, і воно СТАЛИ не вдається. Після цього ви розумієте, що якийсь інший фрагмент коду покладається на цю функцію / метод зовсім по-іншому. Потім ви можете виправити тест і отриманий код. Без такого виду покриття коду, який би ти спотикався цілими днями, намагаючись знайти місце, де щось порушено,

Прочитайте про "Контракти" в книзі Прагматичного прогмера. Тестування допомагає досягти кодових контрактів. Цей код робить X, і не більше, ніж X, і не сподівайтеся, що він щось зробить з Y, або намагайтеся адаптувати його до Z. Він забезпечує чистоту коду і розраховує, що всі не будуть каламутними і каламутними.

Є більше причин для BDD. Головним для мене є те, що я б зробив стільки ж тестування, щоб у будь-якому разі перевірити свої припущення, щоб я міг також формалізувати це.

Від питання "як" це насправді залежить від вашого оточення. Я зараз пишу гру java і використовую роболектрик. Ви завжди повинні намагатися чогось "очікувати". Я чув, що шпигуни / макети / заглушки не такі корисні, оскільки вам потрібно мати еквівалент з іншого боку, але іноді у вас немає вибору, особливо з API. Ви можете припустити, що інша сторона API не є жахливою, і це, як правило, ваш код.

Наприклад, ви протестуєте рух. Добре ви очікуєте, що після натискання кнопки "Вгору" користувач рухається вперед деяким виміром.

Якщо ви, наприклад, тестуєте візуалізацію графіки ... ну не тестуйте це занадто багато, тому що ви це справді робите? Гарна тестова рамка може впоратися з вами цією частиною. Рефлексія не надто тривіальна, я б сказав про такі речі. Можливо, вам доведеться перевірити буфери тощо. Я просто перевірив би, що ви насправді робите. Характер тут, зараз він там після деяких дій.

У вас повинно бути багато маленьких функцій / тестів, і вони разом підсумовують щось корисне.


Нарешті, я помітив багато людей, які так трапляються, щоб отримати правильну поведінку під час кодування ігор / графіки. Тестування свого роду запобігає ефекту "це просто працює". Набагато складніше ЗНАЙТИ, як ваші рівняння вплинуть на речі, ніж просто скопіювати якийсь код і зробити припущення.
Parris

BDD стосується не лише тестування, але й виходить за рамки цього.
Даніель

0

Я відчуваю, що існує неправильне уявлення про те, що таке BDD. BDD - це не техніка чи процес випробування. BDD - це модель розвитку та процес розвитку. Це виходить за межі тестування і виходить за рамки програмування.

Таким чином, я не знаю жодної великої студії AAA, яка б працювала з цією моделлю (у мене є друзі, які працюють для деяких з них в усьому світі як програмісти). Як зазначав хтось інший, можливо, якийсь керівник проекту чи команда десь включає деякі практики, які BDD включає, але я не знаю жодної студії, що застосовує pure-BDD (від визначення вартості бізнесу, до специфікації на прикладі, до написання файли функцій, для перевірки їх власниками акцій, до автоматизації файлів функцій як тестів).

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.