Unit test di un progetto di gioco C # / XNA

Mi diletto nello sviluppo del gioco da quando ho iniziato a programmare, ma mai molto sul serio. Lavoro come sviluppatore di app aziendali, ma sto lavorando ad alcuni giochi nel mio tempo libero.

Nel mondo degli affari (sullo stack Web-dev di Microsft) ASP.NET MVC sta diventando molto popolare, grazie alla sua facilità di test unitari sul funzionamento dell'interfaccia.

Mi chiedo quali schemi di progettazione (MVC, MVP, MVVM, ecc.) Si possano usare per scrivere un gioco in cui tutta la logica del gioco è facilmente testabile dall'unità. È possibile o fattibile? Sto sprecando il mio tempo, è meglio fare build complete e quindi eseguire test di tipo "integrazione" anziché test unitari?

Il codice di esempio sarebbe ottimo, ma è utile anche un writeup.

(Ho provato ad aggiungere un tag di unit test, ma non ho il rappresentante richiesto ...)

— Nate
fonte

Ecco un buon articolo che ho scoperto che descrive un'architettura per separare le funzionalità per renderle non solo facilmente riutilizzabili, ma anche potenzialmente molto più facili da testare:

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

Alcuni giochi trarranno vantaggio da un modello simile a MVC. Mi vengono in mente giochi da tavolo come scacchi e giochi di carte. Nella maggior parte dei casi, tuttavia, si tratta di un enorme sovraccarico.

Personalmente trovo che sia sufficiente testare solo cose di natura algoritmica. Le cose su cui dipenderai "funzioneranno" quando scrivi il codice di gioco e, in caso contrario, può essere insidiosamente difficile rintracciare i problemi. Cose come i test di intersezione o il codice di rete.

(Le cose che idealmente saranno integrate in un framework di terze parti, quindi non devi scrivere o provarle!)

Una tecnica che mi piace usare per i test di unità relativi a giochi è quella che io chiamo "test di unità visiva". Il concetto di base è un semplice rendering di linee del bit di codice in questione (ad esempio una funzione di intersezione) e alcune assegnazioni di base di tasti o mouse per manipolare gli input. Nessuno ha detto che i test unitari debbano essere automatizzati: devono solo scomporre le cose in singole unità e testarle.

— Andrew Russell
fonte

Buona risposta. Volevo anche pubblicare esattamente quell'articolo. I sistemi di componenti Game Game sono un ottimo modo per separare la logica ed essere in grado di testarli singolarmente. Ciò che nessun test unitario può fare, tuttavia, sono le complesse interazioni di percorsi multipli di logica di gioco che interagiscono in tempo reale in sequenza casuale. Sarebbe come provare a testare le previsioni del tempo. :)

— LearnCocos2D

Sì, faccio anche piccoli tester che isolano particolari bit di funzionalità. Mi assicuro che qualsiasi modifica apportata alle API ecc. Mi assicuro sempre che funzioni ancora. Molto più facile riutilizzare la funzionalità nel tuo prossimo progetto.

— Iain,

Sì, buona risposta, e mi piace il link. E ho concordato con tutto fino all'ultima riga, "Nessuno ha detto che i test unitari devono essere automatizzati". :) Hanno a, forse no - ma tutto ho letto'VE implica (o dice a titolo definitivo), che test di unità dovrebbe essere automatizzati , al punto in cui si preme un tasto solo per eseguire tutti i test. Altrimenti, maggiore è il lavoro richiesto per l'esecuzione dei test, minore è la probabilità di eseguirli abbastanza spesso. Certo, se stai parlando di codice di visualizzazione , può essere molto più difficile testare l'unità, se possibile.

— Ciclope,

Quasi quattro anni dopo, e credo di aver sviluppato una migliore comprensione del perché il "test unitario visivo" funzioni così bene: i test unitari sono uno strumento di sviluppo. Un tipico test di unità automatizzato può dirti che qualcosa è rotto. Ma un test di unità visiva può permetterti di esplorare algoritmi molto complicati e aiutarti a identificare rapidamente perché qualcosa non funziona (in particolare se combinato con la modifica del codice live). Spesso un test visivo può identificare problemi che altrimenti dovresti anticipare per testare con il codice o problemi in cui non esiste una risposta "giusta" (ad esempio: ottimizzazione).

— Andrew Russell,

E l'idea che i test unitari debbano essere eseguiti "abbastanza spesso" (come in: sempre, in modo automatizzato) è fasulla. Il codice che non cambia ovviamente non ha bisogno di essere nuovamente testato. E quando il codice viene modificato, lo sviluppatore che sta effettuando le modifiche dovrebbe farlo mentre utilizza i test disponibili appropriati (visivi, basati su codice o altro). Ovviamente esiste un codice con un determinato profilo di rischio in cui un test automatizzato è un investimento utile. Ma tali scenari sono particolarmente rari nello sviluppo del gioco.

— Andrew Russell,