Come progettare un software di gioco in modo che sia facile testare l'unità?

È pratico utilizzare un framework di test come JUnit in una situazione di sviluppo del gioco? Che tipo di considerazioni sul design puoi seguire per rendere il tuo gioco più testabile? Quali parti di un gioco possono / dovrebbero essere testate e quali parti dovrebbero / devono essere lasciate ai test umani?

Ad esempio, se il loop di gioco è incapsulato in una funzione, sembra che sarebbe estremamente difficile testarlo. Mi piace riformattare una funzione di "aggiornamento" che richiede un delta temporale e avanza nella logica del gioco; questo consente alcuni trucchi interessanti come la capacità di rallentare il gioco alimentandolo con delta fasulli e più lenti.

Uno dei principi di TDD è che in alcuni casi lasci che TDD influenzi il tuo design. Scrivi un test per il sistema, quindi scrivi il codice per far passare quel test, mantieni le dipendenze il più superficiali possibile.

Per me, ci sono solo due cose che non collaudo come parte del test unitario:

Innanzitutto, non collaudo gli elementi visivi e l'aspetto delle cose. Lo collaudo e l'oggetto sarà nel posto giusto dopo l'aggiornamento, che una telecamera eliminerà un oggetto al di fuori dei suoi limiti, che le trasformazioni (almeno quelle eseguite al di fuori degli shader) vengono eseguite correttamente prima di essere consegnate al motore grafico , ma una volta che colpisce il sistema grafico traccio la linea. Non mi piace provare a deridere cose come DirectX.

In secondo luogo, non collaudo davvero la funzione principale del loop di gioco. Metto alla prova che ogni sistema funzionerà quando verrà superato un delta ragionevole e che i sistemi funzioneranno insieme correttamente quando necessario. Quindi aggiorno ogni sistema con il delta corretto nel loop di gioco. Potrei effettivamente avere un test per dimostrare che ogni sistema è stato chiamato con il delta corretto, ma in molti casi lo trovo eccessivo (a meno che tu non stia facendo una logica complessa per ottenere il tuo delta, quindi non è eccessivo).

Noel Llopis ha coperto i test unitari nella misura in cui credo che tu stia cercando:

• 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
• (ha anche molti altri articoli su TDD)

Per quanto riguarda il test dell'intero ciclo di gioco, esiste un'altra tecnica per prevenire regressioni funzionali nel codice. L'idea è di far giocare il tuo gioco tramite un sistema di riproduzione (cioè prima registrando gli input del giocatore e poi riproducendoli su una corsa diversa). Durante la riproduzione, si genera un'istantanea dello stato di ciascun oggetto per ogni fotogramma. Questa raccolta di stati può quindi essere definita "immagine d'oro". Quando si esegue il refactoring del codice, si esegue nuovamente il replay e si confronta lo stato di ciascun fotogramma con lo stato dell'immagine dorata. Se differisce, il test ha avuto esito negativo.

Mentre i vantaggi di questa tecnica sono ovvi, ci sono alcune cose con cui devi fare attenzione:

• Il tuo gioco deve essere deterministico, quindi devi fare attenzione a cose come dipendere dal tuo orologio di sistema, eventi di sistema / rete, generatori di numeri casuali che non sono seminati in modo deterministico. eccetera.
• i cambiamenti di contenuto dopo la generazione dell'immagine d'oro possono causare differenze legittime con l'immagine d'oro. Non c'è modo di aggirare questo problema: quando si modificano i contenuti è necessario rigenerare l'immagine d'oro.

Sono d'accordo con entrambi i commenti di Jeff e jpaver. Volevo anche aggiungere che l'adozione di un modello di componente per la tua architettura aumenta notevolmente la sua testabilità. Con un modello di componente ogni componente dovrebbe eseguire una singola unità di lavoro e dovrebbe essere testabile in isolamento (o con oggetti finti limitati).

Allo stesso modo, le altre parti del gioco che si basano su entità dovrebbero fare affidamento solo su un sottoinsieme dei componenti per funzionare. In pratica questo significa che di solito puoi deridere alcuni componenti falsi per facilitare il test di queste aree oppure puoi semplicemente comporre entità parziali a scopo di test. ad esempio si tralasciano i componenti di rendering e input perché non sono necessari per testare la fisica.

Infine, vorrei ignorare i consigli sulle prestazioni che ricevi da alcune persone nella comunità di gioco riguardo alle interfacce. Scrivi bene il codice con le interfacce e se riscontri problemi di prestazioni lungo la strada puoi facilmente profilare, identificare e refactor per risolvere il problema. Non sono stato persuaso dalle preoccupazioni di Noel riguardo all'impatto sulle prestazioni delle interfacce o al sovraccarico di complessità che hanno aggiunto.

Detto questo, non esagerare cercando di provare ogni piccola cosa in modo indipendente. Come la maggior parte delle cose, test e progettazione mirano a trovare il giusto equilibrio.

Ho pensato di aggiungere una seconda risposta rispondendo al commento del PO che l'utente poteva sostituire i test unitari. Credo che sia completamente sbagliato, poiché lo scopo dei test unitari non è garantire la qualità. Se desideri test in atto per garantire la qualità del tuo programma, probabilmente dovresti studiare i test sugli scenari o investire in un monitoraggio eccezionale.

(Con un ottimo monitoraggio e un prodotto in esecuzione come servizio è davvero possibile inviare alcuni "test" sul cliente, ma è necessario disporre di un sistema sofisticato che rilevi rapidamente gli errori e ripristini le modifiche responsabili. Molto probabilmente questo è troppo per un piccolo team di sviluppo.)

Il vantaggio principale dei test unitari è che costringono lo sviluppatore a scrivere codice meglio progettato. L'atto di test sfida lo sviluppatore a separare le preoccupazioni e incapsulare i dati. Incoraggia inoltre lo sviluppatore a utilizzare interfacce e altre astrazioni in modo da testare solo una cosa.