Jak zaprojektować oprogramowanie gry, aby było łatwe do testowania jednostkowego?

Czy praktyczne jest zastosowanie środowiska testowego, takiego jak JUnit, w sytuacji tworzenia gier? Jakie rozważania projektowe możesz zastosować, aby Twoja gra była bardziej testowalna? Jakie części gry można / należy przetestować, a które należy / należy pozostawić do testów na ludziach?

Na przykład, jeśli pętla gry jest zamknięta w jednej funkcji, wydaje się, że testowanie byłoby strasznie trudne. Lubię refaktoryzować funkcję „aktualizacji”, która zajmuje deltę czasu i rozwija logikę gry; pozwala to na kilka interesujących sztuczek, takich jak możliwość spowolnienia gry poprzez podawanie jej fałszywych, wolniejszych delt czasowych.

Jednym z założeń TDD jest to, że pozwalasz TDD w niektórych przypadkach wpływać na twój projekt. Piszesz test dla systemu, a następnie piszesz kod, aby ten test przeszedł pomyślnie, utrzymując zależności tak płytkie, jak to możliwe.

Dla mnie są tylko dwie rzeczy, których nie testuję w ramach testów jednostkowych:

Po pierwsze, nie testuję elementów wizualnych i tego, jak wyglądają rzeczy. Testuję to i obiekt będzie po właściwym uaktualnieniu, że kamera wyrzuci obiekt poza jego granice, że transformacje (przynajmniej te wykonane poza modułami cieniującymi) są wykonywane poprawnie przed przekazaniem do silnika graficznego , ale kiedy trafi w system graficzny, rysuję linię. Nie lubię próbować kpić z takich rzeczy jak DirectX.

Po drugie, tak naprawdę nie testuję głównej funkcji pętli gry. Testuję, czy każdy system będzie działał, gdy minie rozsądną różnicę, i że systemy działają razem poprawnie, gdy trzeba. Następnie po prostu aktualizuję każdy system z poprawną deltą w pętli gry. Mógłbym faktycznie przetestować, aby pokazać, że każdy system został wywołany z poprawną deltą, ale w wielu przypadkach uważam, że to przesada (chyba że robisz skomplikowaną logikę, aby uzyskać deltę, to nie jest to przesada).

Noel Llopis opisał testy jednostkowe w takim stopniu, w jakim, moim zdaniem, szukasz:

• http://gamesfromwithin.com/stepping-through-the-looking-glass-test-driven-game-development-part-1
• http://gamesfromwithin.com/stepping-through-the-looking-glass-test-driven-game-development-part-2
• http://gamesfromwithin.com/stepping-through-the-looking-glass-test-driven-game-development-part-3
• http://gamesfromwithin.com/backwards-is-forward-making-better-games-with-test-driven-development
• (ma również wiele innych artykułów o TDD)

Jeśli chodzi o testowanie całej pętli gry, istnieje inna technika zapobiegania regresjom funkcjonalnym w kodzie. Chodzi o to, aby twoja gra była odtwarzana przez system powtórek (tj. Najpierw rejestrując dane wejściowe odtwarzacza, a następnie odtwarzając je w innym przebiegu). Podczas odtwarzania generujesz migawkę stanu każdego obiektu dla każdej klatki. Tę kolekcję stanów można następnie nazwać „złotym obrazem”. Podczas refaktoryzacji kodu ponownie uruchom powtórkę i porównaj stan każdej klatki ze stanem złotego obrazu. Jeśli się różni, test się nie powiódł.

Chociaż korzyści płynące z tej techniki są oczywiste, jest kilka rzeczy, na które należy uważać:

• Twoja gra musi być deterministyczna, dlatego musisz uważać na takie rzeczy, jak zależność od zegara systemowego, zdarzeń systemowych / sieciowych, generatorów liczb losowych, które nie są determinowane. itp.
• zmiany treści po wygenerowaniu złotego obrazu mogą powodować uzasadnione różnice w stosunku do twojego złotego obrazu. Nie ma sposobu na obejście tego - podczas zmiany treści musisz zregenerować swój złoty obraz.

Zgadzam się z komentarzami Jeffa i Jpavera. Chciałem również dodać, że przyjęcie modelu komponentu do architektury znacznie zwiększa jego testowalność. W przypadku modelu komponentu każdy komponent powinien wykonywać jedną jednostkę pracy i powinien być możliwy do przetestowania w izolacji (lub z ograniczonymi próbnymi obiektami).

Podobnie, inne części gry, które opierają się na bytach, powinny działać tylko na podzbiorze elementów. W praktyce oznacza to, że zwykle można wykpić kilka fałszywych komponentów w celu ułatwienia testowania tych obszarów lub po prostu skomponować częściowe jednostki do celów testowych. np. pomijasz komponenty renderujące i wejściowe, ponieważ nie są one potrzebne do testowania fizyki.

Na koniec zignorowałbym porady dotyczące wydajności, które otrzymujesz od niektórych osób w społeczności gier, dotyczące interfejsów. Pisz dobrze kod z interfejsami, a jeśli napotkasz problemy z wydajnością, możesz łatwo profilować, identyfikować i refaktoryzować rozwiązanie problemu. Nie przekonały mnie obawy Noela dotyczące wpływu interfejsów na wydajność lub złożoności, którą dodali.

To powiedziawszy, nie przesadzaj, próbując przetestować każdą drobiazg niezależnie. Podobnie jak większość rzeczy, testy i projektowanie polegają na znalezieniu właściwej równowagi.

Pomyślałem, że dodam drugą odpowiedź w odpowiedzi na komentarz OP, że użytkownik może zastąpić testy jednostkowe. Uważam, że jest to całkowicie błędne, ponieważ celem testów jednostkowych nie jest zapewnienie jakości. Jeśli chcesz mieć testy w celu zapewnienia jakości programu, powinieneś prawdopodobnie zbadać testy scenariuszy lub zainwestować w doskonały monitoring.

(Dzięki doskonałemu monitorowaniu i produktowi działającemu jako usługa rzeczywiście można przekazać klientowi pewne „testy”, ale trzeba mieć wyrafinowany system, który szybko wykrywa błędy i wycofuje odpowiedzialne zmiany. Najprawdopodobniej jest to zbyt wiele dla mały zespół programistów).

Główną zaletą testów jednostkowych jest to, że zmuszają programistę do pisania lepiej zaprojektowanego kodu. Testowanie wymaga od programisty oddzielenia problemów i enkapsulacji danych. Zachęca również programistę do korzystania z interfejsów i innych abstrakcji, aby testował tylko jedną rzecz.