Strategia di test per i giochi

Question

Strategia di test per i giochi

#1 da (16 voti)

13

Ho ereditato un gioco educativo basato sul web. Nell'ultimo anno ho lavorato per stabilizzare il codice e aggiungere nuove funzionalità. La maggior parte della logica è nel front-end, quindi i test delle unità di back-end, sebbene utili, coprono una piccola percentuale del codice.

Il gioco è arrivato al punto in cui sta iniziando a diventare complesso. Ci sono due diverse modalità per ogni gioco e il gioco si comporta diversamente a seconda della modalità. Ci sono anche varie bandiere che influenzano il gioco.

Sono uno sviluppatore di applicazioni da oltre 10 anni e questo mi lascia perplesso. Nel mondo aziendale, un algoritmo funziona sempre allo stesso modo. Scriverò un test unitario per un algoritmo, prevedo il valore 42 e verrà visualizzato un errore se non ottengo quel valore.

Quando si tratta di giochi, sono perso. Come posso testarli? Ho tester disponibili per me. Posso passare il tempo a scrivere test di unità.

I tester sono ... inaffidabili. Non sono i migliori a risolvere i problemi e non ho dato loro la direzione migliore. A parte passare un sacco di tempo ogni ciclo di rilascio testando ogni permutazione e combinazione del gioco, come dovrei usarli come risorsa?

I test unitari sembrano limitati. Dal momento che la maggior parte della logica è javascript (e ho ereditato il codice spaghetti), posso usare una suite di front-end come Cetriolo o selenio per garantire che alcune funzioni funzionino.

È la migliore strategia? Come fanno le società di giochi a testare i giochi?

Ho letto la domanda " Test Driven Development for Complex Games "(tra gli altri sul sito), ma non affronta ciò che sto cercando. Sto chiedendo strategie, non esempi specifici di come testare.

tdd testing unit-testing games

posta jeffkolez 08.09.2014 - 17:49

fonte

1 risposta

Leggi altre domande sui tag tdd testing unit-testing games

Come gestire il "dogmatismo" tecnologico Perché un piccolo vocabolario fisso è visto come un vantaggio per i servizi RESTful?

score 16 · Accepted Answer

In the enterprise world, an algorithm always functions the same way. I'll write a unit test for an algorithm, I'll expect the value 42 and it'll error if I don't get that value.

Questo non è molto diverso nei giochi. La presenza di due modalità e di più flag nel gioco su cui stai lavorando non cambia nulla: se utilizzi una modalità specifica con un set specifico di flag, otterrai comunque lo stesso valore più e più volte durante il test di una parte di il codice sorgente.

Con troppe modalità e flag, il gioco può diventare rapidamente molto difficile da testare, a causa del numero di possibili varianti. Per mitigare il rischio di incorrere in questa difficoltà in anticipo, dovresti:

Mock / stub severely . Tieni le parti testate piccole e prendi in giro tutto ciò su cui fanno affidamento.

Se si basano sul tempo, prendi in giro l'oggetto tempo per dare sempre un risultato specifico o un insieme di risultati specifici, indipendentemente dal tempo reale.

Se fanno affidamento su random() , prendi in giro per fornire una costante ogni volta.
Refactor . Se i test iniziano a essere eccessivamente complicati o se si vede che una classe, per essere testata, richiede dodici argomenti dopo aver implementato la dipendenza dall'iniezione, mentre prima richiedeva solo due, è necessario rifattorizzare il codice.
Metti in discussione le attuali regole aziendali dell'applicazione. Ho smesso di contare il numero di progetti che erano quasi impossibili da testare a causa del numero di diverse variazioni richieste dai requisiti funzionali che nessuno aveva mai avuto bisogno di intendere, nemmeno le parti interessate.

Quando un piccolo sito di e-commerce ha bisogno di dieci pagine per spiegare i requisiti funzionali utilizzati per determinare come vengono calcolati i prezzi di spedizione, non si dovrebbe iniziare scrivendo test o codice, ma invece si dovrebbe tornare agli stakeholder e lavorare con per produrre sane requisiti.

Infine, automatizza ogni test . I tester sono necessari per scoprire situazioni in cui l'applicazione fallisce. Usando i tester per eseguire, ancora e ancora, la stessa azione ad ogni revisione è controproducente e irrispettosa dei tester: i test di regressione dovrebbero essere eseguiti dalle macchine, non dalle persone. Le persone, d'altra parte, sono molto più brave a trovare possibili bug. "E se io ..." è una delle tecniche che possono usare ("Cosa succede se inserisco alcuni megabyte di dati binari contenenti diversi \ x00 in un campo che chiede la mia età e vediamo cosa accadrà?"), ma possono essere usati anche approcci più formali.