Czy w grach używa się BDD (Behaviour Driven Development)?

Od jakiegoś czasu czytam o BDD - Behaviour Driven Development i uważam, że konwersja funkcji na kod jest naprawdę łatwa i przydatna. Użytkownicy BDD często nazywają to TDD poprawnie.

BDD to narzędzie do projektowania oprogramowania, od zewnątrz do wewnątrz, od wartości biznesowej (lub wartości gry) do kodu.

Dan North przedstawia BDD

Czy znasz inne zasoby na temat BDD i gier poza tym ?

Prawdopodobnie bezpiecznie jest powiedzieć, że BDD, takie jak TDD, lub (wstaw tutaj modny buzzword-paradygmat tutaj) jest używany przez niektórych twórców gier, ale prawdopodobnie nie wiedzą, że nie są, ani też nie byliby w stanie zidentyfikować, co właściwie oznacza BDD . Pytanie naprawdę brzmi, jak bardzo go używają i ile muszą go używać, aby miało to dla Ciebie znaczenie?

Na przykład tam, gdzie pracuję, wszystkie nasze nazwy testów jednostkowych są „zdaniami”, jak sugeruje Dan North w tym artykule, który podłączyłeś. Samo to nie wystarczy, aby powiedzieć, że używamy BDD, oczywiście, ale może to jest to, na czym naprawdę Ci zależy?

Moim zdaniem nie powinno się skupiać na tym, które słowo kluczowe stosujesz w studiu, ale raczej na tym, które techniki produktywności i procesu rozwoju stosujesz ogólnie. Uważam, że najbardziej produktywne zespoły mieszają i dopasowują techniki od różnych „modnych paradygmatów”, zamiast angażować się, dogmatycznie, w każdą sztywną doktrynę, jak twierdzą niektóre badania internetowe, jeden szczególny paradygmat modny.

Widzę to najczęściej z trendem zwinnym: zespoły, które identyfikują się jako „działające zwinne”, są bardziej nieelastyczne (ironicznie) w stosunku do tego procesu niż zespoły, które organicznie włączają fragmenty zwinne, które mają dla nich sens. Z mojego doświadczenia wynika, że ​​poprzednie zespoły prawie zawsze są mniej produktywne.

Zespół programistów składa się z ludzi, którzy nie są wymiennymi trybami w maszynie. Działają wyjątkowo jako jednostki i jako unikalne połączenie siebie. Sposobem na skuteczny rozwój nie jest naginanie ludzi do formy {BDD, Agile, WhthingIsNext}, ale ciągłe ocenianie postępów zespołu i uzupełnianie braków w procesie, zastępowanie uszkodzonych technologii i wzmacnianie rzeczy, które są pracujący. Krótko mówiąc, aby skupić się na wysyłce tytułu, a nie na „byciu zwinnym (lub czymkolwiek)”.

Czy to jest Może. Sądzę, że ogólnie rzecz biorąc bardzo źle pasowałoby do oprogramowania rozrywkowego, chociaż może dobrze działać w przypadku bibliotek niskiego poziomu.

EDYCJA: Oto uzasadnienie mojej opinii.

Wikipedia definiuje BDD jako technikę, która „zachęca do współpracy między programistami, QA i uczestnikami nietechnicznymi lub biznesowymi przy projekcie oprogramowania”. To już wydaje się złym pomysłem, ponieważ gry różnią się od większości oprogramowania tym, że nie są zaprojektowane jako narzędzia zaspokajające specyficzne potrzeby „nietechnicznego lub biznesowego uczestnika”, ale są spójnymi dziełami szeroko zaprojektowanymi do rozrywki. Nacisk kładziony jest na „pożądane zachowanie oprogramowania”, ale gry rzadko mają „pożądane zachowanie oprogramowania”, z wyjątkiem poziomu technicznego. Zdecydowanie warto sprawdzić tę część kodu, ale nie u użytkownika końcowego, ponieważ nigdy go nie zobaczy.

Ale załóżmy, że chcesz wyrzucić te ludzkie interesariusze i po prostu użyć BDD do egzekwowania umów między różnymi modułami kodu, co, o ile widzę, nie różni się zbytnio od normalnego programowania opartego na testach, które również uważam za kiepsko- nadaje się do gier z następującego powodu.

Testy są przydatne do sprawdzania, czy zdarzenia dyskretne miały miejsce w oczekiwanym momencie. Działa to dobrze w programowaniu sterowanym zdarzeniami, tj. większość świata oprogramowania, w którym wykonywana jest akcja, generowane są dane wyjściowe, a następnie po prostu weryfikujesz, czy akcja i wynik są zgodne. Jednak oprogramowanie do gier jest zazwyczaj symulacją, w której akcja nie ma dyskretnego rezultatu, lecz ciągłą zmianę stanu świata. Jeśli mój ukryty odtwarzacz hałasuje, mogę chcieć sprawdzić, czy AI mnie ściga. Mogę więc utworzyć test, aby upewnić się, że AI jest w stanie „polowania” po wytworzeniu hałasu, i to świetnie. Ale skąd mam wiedzieć, że polowanie w ogóle działa? Nie możesz tego sprawdzić natychmiast - możesz to obserwować z upływem czasu.

Ponadto podejście oparte na pierwszej próbie może stworzyć fałszywe poczucie bezpieczeństwa i doprowadzić ludzi do przekonania, że ​​kod jest lepszy niż w rzeczywistości.

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

class Dice:
    def roll():
        return 4

Ponieważ wynik testu może dać wynik fałszywie dodatni, nigdy nie można uniknąć podstawowej potrzeby sprawdzenia samego kodu. Ale jeśli sam kod jest odpowiednio sprawdzony, test ma drugorzędne znaczenie. Dlatego, moim zdaniem, testy najlepiej stosować po wydarzeniu, aby przetestować poprawki błędów.

Nie argumentowałbym, że nigdy nie ma żadnych korzyści z testowania, że ​​kiedy obiekty X i Y współpracują ze sobą, wynik jest zgodny z oczekiwaniami. Problem polega na tym, czy używasz najbardziej skutecznego sposobu weryfikacji tego. Metody mogą obejmować formalną weryfikację, przegląd kodu, metody pierwszego testu, metody ostatniego testu, tradycyjne testowanie czarnej skrzynki QA lub po prostu użycie kodu zgodnie z oczekiwaniami i obserwowanie wyników. Dwie ostatnie opcje są zaskakująco skuteczne przez większość czasu, ponieważ pomimo tego, że brzmią tak, jakby brakowało im rygoru, większość błędów można znaleźć podczas typowego użytkowania, a zrozumienie błędu w jego naturalnym kontekście może czasem być łatwiejsze niż zrozumienie go w sztucznym teście uprząż. Na dodatek

Podsumowując, uważam, że rozwój oparty na testach niekoniecznie jest doskonałym wyborem dla oprogramowania, że ​​same testy nigdy nie są wystarczające do zapewnienia jakości oprogramowania (a zatem czas spędzony na ich pisaniu należy porównać z alternatywnymi zastosowaniami tego czasu programisty), że gry są szczególnie słabym dopasowaniem do automatycznych przypadków testowych oraz że gry są szczególnie słabym dopasowaniem do metod programistycznych, które kładą nacisk na „wartość biznesową” i „testy akceptacyjne”.

(Mam nadzieję, że to lepsza odpowiedź, nawet jeśli nie zgadzasz się z moimi punktami).

Myślę, że BDD jest odpowiednie w każdym środowisku. Jak wspomnieli inni, tworzysz oprogramowanie, dlatego powinieneś je przetestować. Lubię bdd dla niektórych losowych semantyków wymienionych jak nazwy testowe jako zdania. Lubię też grupować niektóre testy razem, wciąż będąc w stanie przetestować 1 klasę.

Aby zwalczyć inne wiadomości tutaj, chciałbym zauważyć, że przy większym projekcie znacznie trudniej jest zmienić kod bez testów. Jeśli zmienisz kod, jesteś ślepy, czy wszystko wybuchnie w blasku chwały, czy nie. Testy pomagają wcześnie złapać rzeczy. Więc piszesz test, nie powiodło się, kod wystarczy, aby przejść i kontynuować. Po refaktoryzacji powinieneś zrobić to samo, ale zamiast pisać, popraw test. W większości przypadków uruchomienie testu zakończy się niepowodzeniem, zmienisz to, co Twoim zdaniem powinno się zmienić, i nadal będzie zawieść. W tym momencie zdajesz sobie sprawę, że jakiś inny fragment kodu opiera się na tej funkcji / metodzie w zupełnie inny sposób. Następnie możesz naprawić test i wynikowy kod. Bez tego rodzaju kodu, przez kilka dni próbujesz znaleźć miejsce, w którym coś się psuje,

Przeczytaj o „Kontraktach” w książce Pragmatic Progammer. Testowanie pomaga osiągnąć kontrakty na kod. Ten kod robi X i nic więcej niż X i nie oczekuj, że zrobi coś z Y lub spróbujesz go przystosować do Z. Zapewnia czystość kodu i oczekuje, że wszyscy nie będą kutasem i nie popsują bazy kodu.

BDD ma więcej powodów. Najważniejsze dla mnie jest to, że zrobiłbym tyle samo testów, aby zweryfikować moje założenia i tak, że równie dobrze mogę je sformalizować.

W kwestii „jak” to naprawdę zależy od twojego środowiska. Piszę teraz grę Java i korzystam z robolectric. Zawsze powinieneś próbować „czegoś” oczekiwać. Słyszałem, że szpiedzy / drwiny / odcinki nie są tak przydatne, ponieważ po drugiej stronie musisz mieć odpowiednik, ale czasami nie masz wyboru, szczególnie z interfejsami API. Możesz założyć, że druga strona interfejsu API nie jest straszna i zwykle to twój kod jest do bani.

Jeśli na przykład testujesz ruch. Oczekujesz, że po naciśnięciu przycisku „w górę” użytkownik przesunie się do przodu o pewien pomiar.

Jeśli na przykład testujesz renderowanie grafiki ... nie testuj tego za bardzo, bo tak naprawdę to robisz? Dobry framework testowy może obsłużyć tę część za Ciebie. Refleksja nie jest bardzo trywialna, powiedziałbym o takich rzeczach. Może być konieczne sprawdzenie buforów itp. Po prostu sprawdzę, co faktycznie robisz. Postać jest tutaj, teraz jest po akcji.

Powinieneś mieć mnóstwo małych funkcji / testów, które razem podsumują coś przydatnego.

Wydaje mi się, że istnieje błędne przekonanie o tym, czym jest BDD. BDD nie jest techniką ani procesem TESTOWANIA. BDD to model i proces rozwoju. To wykracza poza testowanie i wykracza poza programowanie.

W związku z tym nie znam żadnego dużego studia AAA pracującego z tym modelem (mam znajomych pracujących dla niektórych z nich na całym świecie jako programistów). Jak ktoś inny zauważył, być może jakiś kierownik projektu lub zespół gdzieś stosuje niektóre praktyki BDD, ale nie znam żadnego studia stosującego czystą BDD (od definicji wartości biznesowej, przez specyfikację przez przykład, po pisanie pliki funkcji, sprawdzanie ich poprawności u akcjonariuszy, automatyzacja plików funkcji jako testów).