Autor Wątek: Pisanie GUI oraz projekt ich klas w UML  (Przeczytany 7302 razy)

Offline rm-f

  • Użytkownik
    • Tu trolluje

# Marzec 13, 2012, 15:26:08
Bla bla bla bla

A mówiłem, dajcie przykład z życia, to nie.

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline hashedone

  • Użytkownik

  • +3
# Marzec 13, 2012, 15:46:40
Ja w ogóle nie rozumiem tu podejścia "obrońców" TDD. Osobiście uważam że TDD jest zaje... bardzo dobrym sposobem pisania aplikacji. Sam stosuję i w pracy i we własnych aplikacjach. Ale pisanie w metodologii TDD gry to jak pisanie GUI. Gra to nie silnik. Gra to nie assety. Gra to nie algorytmy, fizyka, czy inne ustrojstwo. 80% testowalnego kodu w grach to middleware które jest obtestowane lub nie, ale programisty który takiego mw używa jest to nie istotne - ma działać, jak nie działa to być może znalazłem bug więc go publikuję twórcą, a oni napiszą test, poprawią i puszczą test, lub po prostu poprawią i przetestują w jakiś inny sposób. Gra zaś to imho przede wszystkim powiązania między wszystkimi jej komponentami. A jeśli mówimy o powiązaniach to już nie mówimy o UT. W najlepszym przypadku mówimy o MT, ale tak na prawdę MT to testy które testują integralne grupy obiektów, nie zależności między niezaleznymi modułami. Gry można by testować na poziomie integracyjnym, ale ludzie - w przypadku gier samo zdefiniowanie takich testów trwało by tyle co pisanie samej gry (tak się testuje GUI, czy narzędzia, gdzie ilość usecasów jest stosunkowo mała, nie grę, gdzie usecasów właściwie nie da się wszystkich rozpisać - rozpisuje się co najwyżej uogólnienia). W grze ważniejsze od automatycznego testowania jest testowanie grywalności, ale tego już automat nie zrobi. Do tego potrzebny tester z możliwością szybkiej zmiany jakiś parametrów rozgrywki.
Co do gier Indie w których faktycznie piszę się natywnie w jakimś OGLu, fizykę się implementuje samemu, a jako input łapie komunikaty WinAPI - jak ktoś już powiedział, do małych gier UT to strata czasu.

Offline Kos

  • Użytkownik
    • kos.gd

  • +1
# Marzec 14, 2012, 11:22:57
Bez modelu obiektowego ciężko jest uzyskać 'decoupling' na sensownym poziomie, żeby możliwe było TDD(i pochodne wersje).

Nie zgadzam się; zdecydowanie można mieć decoupling bez OO lub OO bez decouplingu :).