Jednostka Testuje projekt gry C # / XNA

Od czasu, gdy zacząłem programować, zwlekam. Pracuję jako programista aplikacji biznesowych, ale w wolnym czasie pracuję nad niektórymi grami.

W świecie biznesu (na stosie web-dev Microsft) ASP.NET MVC staje się bardzo popularny ze względu na łatwość testowania jednostkowego działania interfejsu.

Zastanawiam się, jakich wzorców projektowych (MVC, MVP, MVVM itp.) Można użyć do napisania gry, w której cała logika gry jest łatwa do testowania jednostkowego. Czy to jest możliwe czy wykonalne? Czy marnuję czas, czy lepiej jest wykonywać pełne kompilacje, a następnie przeprowadzać testy typu „integracyjne” zamiast testów jednostkowych?

Przykładowy kod byłby świetny, ale przydatny jest również zapis.

(Próbowałem dodać tag testu jednostkowego, ale nie mam wymaganego przedstawiciela ...)

— Nate
źródło

Oto dobry artykuł, który znalazłem, który opisuje architekturę oddzielania funkcji, dzięki czemu jest nie tylko łatwa do ponownego użycia, ale także potencjalnie znacznie łatwiejsza do testowania jednostkowego:

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

Niektóre gry będą korzystać ze wzoru podobnego do MVC. Przychodzą mi na myśl gry planszowe, takie jak szachy i gry karciane. W większości przypadków jest to jednak nadmierna nadwyżka.

Osobiście uważam, że wystarczy przetestować tylko jednostki, które mają charakter algorytmiczny. Rzeczy, na których będziesz polegać, aby „po prostu działać”, gdy piszesz kod gry, i może być podstępnie trudne do wyśledzenia problemów, jeśli nie. Rzeczy takie jak testy skrzyżowań lub kod sieci.

(Rzeczy, które idealnie będą wbudowane w frameworki innej firmy, więc nie musisz ich pisać ani testować!)

Jedną z technik, które lubię stosować do testowania jednostek związanych z grą, jest tak zwany „wizualny test jednostek”. Podstawową koncepcją jest proste renderowanie wiersza fragmentu kodu (powiedzmy na przykład funkcja przecięcia) oraz niektóre podstawowe przypisania klawiszy lub myszy do manipulowania danymi wejściowymi. Nikt nie powiedział, że testy jednostkowe muszą być zautomatyzowane - wystarczy rozbić je na poszczególne jednostki i przetestować.

— Andrew Russell
źródło

Dobra odpowiedź. Chciałem też opublikować dokładnie ten artykuł. Systemy komponentów Game Object to świetny sposób na oddzielną logikę i możliwość indywidualnego przetestowania ich. Jednak żaden test jednostkowy nie jest w stanie wykonać złożonych interakcji wielu ścieżek logiki gry oddziałujących w czasie rzeczywistym w losowej sekwencji. To byłoby jak próba jednostkowego przetestowania prognozy pogody. :)

— LearnCocos2D

Tak, tworzę też małe testery, które izolują poszczególne elementy funkcjonalności. Dbam o wszelkie zmiany, które wprowadzam w interfejsach API itp. Zawsze upewniam się, że nadal działają. Znacznie łatwiej jest ponownie wykorzystać tę funkcjonalność w następnym projekcie.

— Iain

Tak, dobra odpowiedź i podoba mi się link. I zgodziłem się ze wszystkim do ostatniej linii: „Nikt nie powiedział, że testy jednostkowe muszą być zautomatyzowane”. :) Muszę , a może nie - ale wszystko, co przeczytałem, sugeruje (lub mówi wprost), że testy jednostkowe powinny być zautomatyzowane , do tego stopnia, że wystarczy nacisnąć jeden przycisk, aby uruchomić wszystkie swoje testy. W przeciwnym razie im więcej pracy będzie wymagało uruchomienia testów, tym rzadziej będziesz je uruchamiał wystarczająco często. To prawda, że jeśli mówisz o kodzie wyświetlania , testowanie jednostkowe może być znacznie trudniejsze, jeśli to możliwe.

— Cyklop

Prawie cztery lata później i wydaje mi się, że lepiej zrozumiałem, dlaczego „wizualny test jednostkowy” działa tak dobrze: testy jednostkowe są narzędziem programistycznym. Typowy automatyczny test jednostkowy może stwierdzić, że coś jest zepsute. Ale wizualny test jednostkowy pozwala odkryć bardzo skomplikowane algorytmy i pomóc szybko zidentyfikować przyczynę uszkodzenia (szczególnie w połączeniu z edycją kodu na żywo). Często test wizualny może zidentyfikować problemy, które w innym przypadku należałoby spodziewać się przy użyciu kodu lub problemy, w których nie ma „właściwej” odpowiedzi (np. Strojenie).

— Andrew Russell,

Pomysł, że testy jednostkowe muszą być przeprowadzane „wystarczająco często” (jak w: zawsze w sposób zautomatyzowany) jest fałszywy. Kod, który się nie zmienia, oczywiście nie musi być ponownie testowany. A gdy kod jest modyfikowany, programista dokonujący modyfikacji powinien to zrobić, wykorzystując odpowiednie dostępne testy (wizualne, oparte na kodzie lub w inny sposób). Oczywiście istnieje kod o pewnym profilu ryzyka, w którym zautomatyzowany test jest opłacalną inwestycją. Ale takie scenariusze są szczególnie rzadkie podczas tworzenia gier.

— Andrew Russell