Odziedziczyłem internetową grę edukacyjną. W ciągu ostatniego roku pracowałem nad ustabilizowaniem kodu i dodaniem nowych funkcji. Większość logiki znajduje się w interfejsie, więc testy jednostek zaplecza, choć pomocne, obejmują niewielki procent kodu.
Gra osiągnęła punkt, w którym zaczyna się komplikować. Istnieją dwie różne tryby dla każdej gry, a gra zachowuje się inaczej w zależności od trybu. Istnieją również różne flagi, które wpływają na grę.
Jestem programistą aplikacji od ponad 10 lat i to mnie niepokoi. W świecie korporacyjnym algorytm zawsze działa w ten sam sposób. Napiszę test jednostkowy algorytmu, spodziewam się wartości 42 i błąd, jeśli nie otrzymam tej wartości.
Jeśli chodzi o gry, jestem zagubiony. Jak je przetestować? Mam do dyspozycji testerów. Potrafię spędzać czas na pisaniu testów jednostkowych.
Testerzy są ... zawodni. Nie są najlepsi w eliminowaniu problemów i nie dałem im najlepszego kierunku. Jak spędzić mnóstwo czasu w każdym cyklu wydawniczym na testowaniu każdej permutacji i kombinacji gry, jak powinienem wykorzystać je jako zasób?
Testy jednostkowe wydają się ograniczone. Ponieważ większość logiki to javascript (i odziedziczyłem kod spaghetti), mogę użyć pakietu front-end, takiego jak Cucumber lub selen, aby upewnić się, że pewne funkcje działają.
Czy to najlepsza strategia? Jak firmy produkujące gry testują gry?
Przeczytałem pytanie „ Test Driven Development for Complex Games ” (między innymi na stronie), ale nie dotyczy tego, czego szukam. Proszę o strategie, a nie konkretne przykłady testowania.
źródło
Odpowiedzi:
Nie różni się to zbytnio w grach. Obecność dwóch trybów i wielu flag w grze, nad którą pracujesz, niczego nie zmienia: jeśli wybierzesz określony tryb z określonym zestawem flag, nadal będziesz otrzymywać tę samą wartość wielokrotnie podczas testowania części kod źródłowy.
Przy zbyt wielu trybach i flagach gra może szybko stać się bardzo trudna do przetestowania ze względu na liczbę możliwych wariantów. Aby zmniejszyć ryzyko wcześniejszego napotkania tej trudności, należy:
Surowo wyśmiewanie / odgałęzienie . Utrzymuj testowane części małe i kpij ze wszystkiego, na czym polegają.
Jeśli polegają na czasie, wyśmiewaj obiekt czasu, aby zawsze dawał określony wynik lub zestaw konkretnych wyników, niezależnie od rzeczywistego czasu.
Jeśli polegają
random(), wyśmiewaj się, aby za każdym razem zapewnić stałą.Refaktor . Jeśli testy zaczynają być zbyt skomplikowane lub jeśli zauważysz, że klasa, aby zostać przetestowana, wymaga dwunastu argumentów po wdrożeniu Wstrzykiwania zależności, podczas gdy wymagała tylko dwóch wcześniej, musisz ponownie kodować.
Podaj w wątpliwość rzeczywiste reguły biznesowe aplikacji. Przestałem liczyć liczbę projektów, które były prawie niemożliwe do przetestowania ze względu na liczbę różnych odmian wymaganych przez wymagania funkcjonalne, których nikt nie potrzebował ani nie rozumiał - nawet interesariuszy.
Gdy niewielka strona internetowa zajmująca się handlem elektronicznym potrzebuje dziesięciu stron do wyjaśnienia wymagań funkcjonalnych zastosowanych do ustalenia, w jaki sposób obliczane są ceny wysyłki, nie należy zaczynać od pisania testów lub kodu, ale zamiast tego należy wrócić do interesariuszy i współpracować z nimi przy tworzeniu rozsądne wymagania.
Wreszcie, zautomatyzuj każdy test . Testerzy są potrzebni do wykrycia sytuacji, w których aplikacja nie działa. Używanie testerów do wielokrotnego wykonywania tego samego działania przy każdej wersji przynosi efekt przeciwny do zamierzonego i nie budzi szacunku dla testerów: testy regresji powinny być wykonywane przez maszyny, a nie przez ludzi. Z drugiej strony ludzie są znacznie lepsi w znajdowaniu możliwych błędów. „Co jeśli ja ...” to jedna z technik, które mogą zastosować („Co jeśli wprowadzę kilka megabajtów danych binarnych zawierających kilka \ x00 w polu, które prosi o podanie mojego wieku i zobaczę, co się stanie?”), ale można również zastosować bardziej formalne podejście.
źródło