Come si fa a testare l'unità in un motore di gioco?

Con mia grande vergogna, non ho mai scritto un test unitario adeguato, solo piccoli programmi di test non organizzati che avrei poi smaltito dopo il superamento del test. Non ho davvero le idee chiare su come eseguire i test unitari in un progetto di gioco. (La mia lingua è C ++.)

Dovrei avere un progetto separato per ciascun sottosistema nel mio motore e un test associato con esso, e quindi avere un progetto / soluzione più grande che costruisca il motore reale? Supponiamo ad esempio che ho il eventmodulo nel mio motore; come dovrei gestirlo?

Innanzitutto, avresti bisogno di un framework di test unitari. In passato ho usato UnitTest ++ e Google Test . Il primo è molto leggero e il secondo è più caratterizzato ma un po 'più ingombrante. Si integra bene con Google Mock se mai avessi bisogno di quel genere di cose. Ci sono ovviamente molte altre opzioni: vedi questo elenco ( per esempio dall'autore di UnitTest ++) e Wikipedia .

Il test unitario riguarda la scrittura di test focalizzati per sottolineare particolari bit di codice indipendenti ("unità") in vari scenari. Mentre in alcuni casi puoi testare tutto, di solito non è pratico ottenere una copertura del 100% e, specialmente nei giochi, può essere abbastanza difficile - è discutibile se il test dell'unità di output del tuo renderer sia in qualche modo significativo, utile o un "vero" unit test indipendentemente.

È importante ricordare che qualsiasi test (automatizzato) è meglio di nessun test (automatizzato). Quindi non dovresti sottolineare troppo il fatto che i tuoi test non sono "veri test unitari" ed essere orgoglioso di avere semplicemente dei test. I framework di unit test sono generalmente utili per la realizzazione di test "non unitari" più ampi, poiché includono funzionalità per i test di imballaggio e per la segnalazione uniforme dei guasti.

Ti incoraggio a resuscitare i tuoi vecchi test e inserirli in un progetto di test utilizzando uno dei framework disponibili, qualcosa che puoi facilmente eseguire di volta in volta (o automaticamente come parte di una versione di rilascio o integrazione) che esegue tutti i tuoi test. Scrivi nuovi test per bit di codice quando diventa evidente che ti sarebbero utili, ad esempio se scopri un bug sottile che potresti aver rilevato con un test, puoi aggiungerne uno per catturare eventuali regressioni che potresti fare in futuro.

Probabilmente scoprirai che è soprattutto il tuo codice di utilità di livello inferiore che è suscettibile di unit test, nei giochi. Va bene - questo è il codice di base che potrebbe disturbare molti livelli superiori se si rompe.

Non andrai al purgatorio del programmatore per non avere test per ogni piccola funzione e porta logica nella tua base di codice, quindi non dedicare più tempo di quanto necessario per scrivere test. Se devi pensare di più o impiegare molto più tempo a scrivere i test per un modulo di quanto non ti ci sia voluto per creare il modulo in primo luogo, potresti perdere tempo. I test unitari - i test in generale - sono uno strumento che impari ad usare in modo appropriato per aiutarti, non un compito che devi svolgere per tutto.

C'è una grande serie di post sul blog sull'uso di TDD e test unitari per lo sviluppo di giochi qui: http://gamesfromwithin.com/stepping-through-the-looking-glass-test-driven-game-development-part-1

Una "unità" è il più piccolo pezzo di codice testabile, in genere una singola funzione o classe. Un unit test è un altro pezzo di codice che esercita quell'unità di codice per assicurarsi che si comporti come previsto. Una singola unità di codice può avere molti test, al fine di coprire tutti i casi.

In genere, i test non sono inclusi nella build principale di un progetto. Piuttosto, esiste una configurazione di build separata per i test che include tutto il codice di test e produce un programma che esegue tutti i test e riporta i risultati. Un framework di test fornirà tutte le impalcature per questo ed è raccomandato, anche se non strettamente necessario. Se sei completamente nuovo ai test, potresti essere meglio scrivere all'inizio il tuo banco di prova ad hoc, per assicurarti di capire tutto ciò che sta accadendo.

Copri più codice che puoi con i test, dando la priorità al codice di cui non sei sicuro o al codice che è fragile e potrebbe essere rotto da future modifiche. Dovresti eseguire i test spesso, idealmente dopo ogni modifica del codice.