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).