È il test-driven development un normale approccio nello sviluppo del gioco?

Sono solo curioso di sapere in quanto tutti TDD esempi che ho visto è la programmazione web correlati. E se non è un normale approccio, perché non lo è?

  • Si potrebbe si prega di includere il nome completo “Test Driven Development” da qualche parte nella tua Domanda? Non sono sicuro se tutti kowns quello che è, e una breve Domanda come questa trucchi non dare un indizio se non conosci la sigla.
  • Se si sa cosa il Test Driven Development è, credo che si sa cosa TDD è così ma io a cambiare il titolo in caso
InformationsquelleAutor terjetyl | 2009-03-06

 

8 Replies
  1. 54

    TDD è diventato un favorito un approccio da sviluppatori di software che sono sul serio la loro professione. [IEEE:TDD] I vantaggi di questo approccio sono notevoli, e i costi sono bassi rispetto. [Le Tre Leggi di TDD]

    Non ci sono software domini per i quali TDD è inappropriato, o inefficace. Tuttavia, ci sono ambiti nei quali è difficile. Di gioco capita di essere uno di questi.

    In realtà, la sfida non è tanto il gioco è UI. Il motivo per UI è una sfida, è che spesso non si sa cosa si desidera che l’interfaccia utente simile fino a quando hai visto. UI è una di quelle cose che si hanno a giocherellare con. Ottenere è proprio un profondo processo iterativo che è pieno di colpi di scena e si trasforma e finisce morto e vicoli. Prove di scrittura primo per l’interfaccia utente è probabile che sia difficile e dispendioso.

    Ora prima di tutti ruggisce fuori e dice: “Zio Bob dice: ‘non TDD per UI'” lasciatemi dire questo. Il fatto che è difficile fare di puro TDD per UI non significa che non si può fare pure TDD per quasi tutto il resto. Molto del gioco è di circa algoritmo, e si può utilizzare TDD con questi algoritmi a vostro piacere. È vero, soprattutto nel gioco, e che alcuni di questi algoritmi sono il tipo di codice da smanettare, proprio come UI, e quindi probabilmente non sono suscettibili di essere testato primo. Ma c’è un sacco di altre codice algoritmico che può e deve essere prova scritta prima.

    Il trucco è quello di seguire il unico principio di responsabilità (SRP) e separare i tipi di codice che devi smanettare, da quei tipi che sono deterministiche. Non mettere più facile test di algoritmi con l’interfaccia utente. Non mescolare il vostro codice speculative con il tuo carattere non speculativo codice. Tenere le cose che cambiano per la ragione separato dalle cose che cambiano per la ragione B.

    Inoltre, tenere questo in mente: Il fatto che un po ‘ di codice è difficile test primo, non significa che questo codice è difficile da testare secondo. Una volta che si hanno manipolato e modificato e ottenuto il codice funziona solo il modo che ti piace, poi è possibile scrivere i test dimostrano che il codice funziona il modo in cui pensi. (Sarete sorpresi di come molte volte si trovano bug mentre si fa questo.)

    Il problema con la scrittura di test “dopo il fatto” è che spesso il codice è così unita che è difficile scrivere i tipi di chirurgica prove che sono più utili. Quindi, se si sta scrivendo il tipo di codice che è difficile test primo, si dovrebbe prendere cura di seguire le dipendenza inversione di principio (DIP), e il aperto/chiuso principio (OCP), al fine di mantenere il codice disaccoppiato abbastanza verificare dopo il fatto.

    • Questo post in modo chiaro e preciso, evidenziando le problematiche del TDD approccio, e la sua evangelisti. Si è visto non come un utile strumento per risolvere alcuni dei problemi incontrati nello sviluppo di software, ma un onnipresente set del libro “principi” che deve essere applicato a tutti i costi, ovunque.
    • Concordato Rune, anche se credo che tutti noi abbiamo molto da imparare da UB SOLIDI principi sono spesso spenti dalla inflessibile modo che egli e i suoi seguaci consegnare i loro sermoni.
    • Mi piace chiamare il cargo cult fiscale. Questi sono dogmatici, approcci progettuali. Davvero tutti TDD è stretto cicli di feedback per aiutare la progettazione di un sistema. Dogmaticamente tirando oltre che delle cose solo perché “viola” SRP è miope. OCP è ancora un’altra coperta di sicurezza, la mia suite di test mi permette di cambiare rapidamente e sapere se ho rotto qualcosa, senza dover utilizzare l’ereditarietà/composizione. DI c’è per noi ragazzi che si occupano di linguaggi tipizzati in modo statico. Che è anche abusato. Perché andiamo attraverso la cerimonia di estrazione di un’interfaccia quando siamo in grado DI un delegato per rendere verificabile?
    • “TDD è diventato un favorito un approccio da sviluppatori di software che sono sul serio la loro professione”. Fallacia. Cinque anni dopo, lo Zio Bob ha cambiato idea su TDD e Professionalità. Penso TDD è diventato un favorito un approccio da parte di persone che vivono l’insegnamento di TDD.
    • Se pensi che l’articolo che hai linkato mostra Zio Bob, cambiando la sua mente, penso che avete bisogno di andare e riletto… I don't believe that TDD is a *prerequisite* to professionalism... it currently plays a significant role in professional behavior... it will play a much greater role as we look into the future. poi confronta i programmatori a non fare TDD i medici non si lavavano le mani, e si chiude con today, at this moment in our history, TDD is not the prerequisite of professionalism that I believe it will become.
    • esattamente, ha cambiato la sua mente, perché prima ha detto (un sacco di volte, io.e 2007 dibattito con James Coplien) che TDD È un prerequisito per la professionalità. Ma che dichiarazione è portare un sacco di polemiche con un sacco di programmatori professionisti che non TDD (come quelli che cita il post). Quindi, sì, ha cambiato idea.
    • Beh, se non il suo punto di vista sono leggermente cambiate negli anni, a me sembra che lui è ancora abbastanza morto insieme a TDD essere una parte importante di un programmatore professionista del tookit. E prendo uno dei suoi anti-TDD esempi, ci sono alcuni vorrebbero descrivere DHH come meno professionale.
    • Sono d’accordo, ma il punto è, lo Zio Bob ora ammette che non è necessariamente bisogno di fare TDD per essere sul serio la vostra professione. E sul codone video, è un ottimo esempio di un ad hominem fallacia…

  2. 19

    La semplice risposta è “no”, TDD non è un normale approccio nello sviluppo del gioco. Alcune persone, punto di Highmoon e Neil Llopis come contro-esempi, ma è una grande industria e loro sono le uniche persone che conosco che hanno pienamente abbracciato TDD. Sono sicuro che ci sono altri, ma sono gli unici che conosco (e ho lavorato nel settore per 5 anni).

    Penso che molti di noi hanno dilettato in unit test a un certo punto, ma per un motivo o per un altro non ha preso piede. Parlando per esperienza personale, è difficile per uno studio di produzione di giochi per passare a TDD. Di solito una codebase è tenuto da un progetto all’altro, e l’applicazione di TDD per una grande base di codice esistente è un’operazione noiosa e in gran parte ingrato. Sono certo che alla fine si rivelerà fruttuosa, ma sempre giochi programmatori per il buy in è difficile.

    Ho avuto un certo successo nella scrittura di test unitari per il basso livello di motore di gioco codice, perché il codice tende ad avere pochissime dipendenze ed è facilmente incapsulato. Questo è sempre stato il test dopo il fatto, e se non TDD. Il più alto livello di codice del gioco è di solito più difficile da scrivere test perché è molto più dipendenze e spesso è associata a dati complessi e di stato. L’assunzione di IA come un esempio, per testare AI richiedono un certo tipo di contesto, il significato di una navigazione a maglia e altri oggetti nel mondo. L’impostazione di che tipo di test in isolamento può essere non banale, soprattutto se i sistemi non sono stati progettati per esso.

    Ciò che è più comune nello sviluppo del gioco, e ho avuto più successo personale, è la prova del fumo. Vedrete spesso il fumo di test utilizzato in combinazione con l’integrazione continua per fornire vari tipi di feedback sul comportamento del codice. Prova del fumo è più facile, perché esso può essere fatto da soli alimentazione dati per il gioco e la lettura di informazioni, senza dover suddividere il codice in minuscolo testabile pezzi. L’assunzione di IA come esempio di nuovo, si può dire che il gioco si carichi di un livello e di fornire uno script che carica una IA agente e dà i comandi. Quindi è sufficiente determinare se l’agente esegue i comandi. Questo è un test del fumo, piuttosto che un test di unità, perché si utilizza il gioco come un insieme e non prova il sistema di intelligenza artificiale in isolamento.

    A mio parere, è possibile ottenere un dignitoso test di copertura di unit test, il codice di basso livello mentre il fumo di provare l’elevato livello di comportamenti. Penso (spero) che altri studi sono in corso anche un approccio simile.

    Se il mio parere di TDD suona un po ‘ ambiguo perché è. Io sono ancora un po ‘ sul recinto su di esso. Mentre vedo alcuni benefici (test di regressione, l’accento sul design prima del codice), applicare e far applicare mentre si lavora con un pre-esistente codebase sembra come una ricetta per il mal di testa.

    • Penso che quello che vuoi dire è il test del sistema (“test condotti su un sistema completo e integrato”), piuttosto che la prova del fumo (“il primo test effettuato dopo il montaggio o riparazione di un sistema, per fornire qualche garanzia che il sistema sotto test non fallire catastroficamente”). (Citazioni tratte dai rispettivi articoli di Wikipedia.)
  3. 10

    Giochi da Interno ha un articolo discutere il loro uso di test di unità, le limitazioni dei test di unità per quanto riguarda i giochi, in particolare, e di un sistema automatizzato di test funzionali server che sono impostati per aiutare con questo.

  4. 5

    Se si fa riferimento alla pratica di scrittura e manutenzione di test di unità per ogni bit di codice, mi permetto di indovinare e dichiarare che questo non è molto diffuso nell’industria del gioco. Ci sono molte ragioni per questo, ma posso pensare di 3 ovvie:

    • Culturale. I programmatori sono conservatori, i programmatori del gioco doppiamente.
    • Pratico. TDD non si adatta molto bene per il dominio del problema (troppe parti in movimento).
    • Crunchological. Non c’è mai abbastanza tempo.

    TDD paradigma funziona meglio in applicazione domini che non sono molto stateful, o almeno le parti in movimento non sono tutti in movimento, allo stesso tempo, per dirla volgarmente.

    TDD è applicabile alle parti del processo di sviluppo del gioco (fondazione biblioteche e simili), ma di “test” in questa linea di lavoro di solito significa esecuzione automatica fly-through, chiave casuale test, i tempi io carichi, monitoraggio fps picchi, assicurandosi che il giocatore non può tirarsi la sua strada in causa visual instabilità, e cose simili. L’automa è anche molto spesso di un umanoide.

    TDD può essere un utile strumento, ma il suo status come un proiettile d’argento che deve-essere-onnipresente-quando-fare-un-sistema è piuttosto discutibile. Lo sviluppo non dovrebbe essere guidato dai test, ma dalla ragione. RDA è un acronimo di merda perché non prendere sul. 😉

  5. 2

    Probabilmente la ragione principale è che il TDD è preferito da coloro con i linguaggi più favorevole ad esso. Ma a parte questo, i giochi stessi sono un povero match per il paradigma comunque.

    In generale (e sì, intendo proprio in generale, quindi, si prega di non palude me con controesempi), test-driven design funziona meglio per event-driven systems e non così bene per simulazione in stile sistemi. È comunque possibile utilizzare test su tutti i componenti di basso livello per i giochi, se il test-driven o semplicemente i test di unità, ma per di più elevato livello di attività raramente vi è alcun tipo di eventi discreti, che si può simulare con risultati deterministici.

    Per esempio, un’applicazione web è in genere molto distinti ingressi (una richiesta HTTP), cambiamenti di una quantità molto piccola di stato (per esempio, i record nel database), e genera una gran parte deterministica di uscita (per esempio, una pagina HTML). Questi possono essere facilmente verificata la validità, e dal momento che la generazione di input è semplice è banale per creare prove.

    Tuttavia con giochi di input può essere difficile da simulare (in particolare se si verificano ad un certo punto… pensare di ottenere passato le schermate di caricamento, schermate di menu, etc.), la quantità di stato si modifica può essere di grandi dimensioni (ad esempio, se si dispone di un sistema di fisica, o complesso reattiva AI) e l’uscita è raramente deterministico (numero casuale uso è il principale colpevole qui, anche se le cose come precisione in virgola mobile a perdita è un altro, come potrebbero essere le specifiche hardware, o il tempo di CPU disponibile, o l’esecuzione di un thread in background, etc.).

    Fare TDD è necessario sapere esattamente che cosa si aspetta di vedere in un determinato evento e di avere un modo preciso di misura, e due di questi sono difficili problemi con simulazioni che evitare gli eventi discreti, volutamente includono fattori casuali, di agire in modo diverso su diverse macchine, e dispone di uscite analogiche come la grafica e l’audio.

    Inoltre, c’è un enorme problema pratico, che è il processo di avvio. Molte delle cose di cui si vuole testare la richiedono il caricamento di grandi quantità di dati, e se si mock-up dei dati non siete veramente il test dell’algoritmo. Con questo in mente, si rapidamente diventa impraticabile per qualsiasi tipo di prova impalcature che esegue solo compiti individuali. È possibile eseguire i test su un server web, senza dover prendere il webserver giù ogni volta che raramente possibili con i giochi a meno di fare il test da un linguaggio di scripting incorporato (che è ragionevole, e in effetti prendere posto nel settore).

    Per esempio, si desidera aggiungere volumetrica ombra di rendering per i tuoi edifici. Quindi avresti bisogno di scrivere un test che viene avviato tutte le necessarie sottosistemi (ad esempio, renderer, gioco, caricatori di risorse), di carico, di edifici (incl. mesh, materiali/texture), di carico, di una macchina fotografica, la posizione della fotocamera a punto presso l’edificio, di attivare le ombre, il rendering di una scena, e quindi in qualche modo decidere se le ombre compaiono nel frame buffer. È meno pratico. In realtà avresti tutta questa impalcatura già presente in forma di gioco, e devi solo sparare fino a condurre un test visivo, oltre a tutte le dichiarazioni all’interno del codice stesso.

  6. 1

    La maggior parte degli sviluppatori di giochi non sono esattamente con esso in termini di moderne pratiche di sviluppo. Per fortuna.

    Ma un test-driven modello di sviluppo sottolinea sapere qualcosa dovrebbe essere usato prima, quindi tirar fuori ciò che fa. Che, in generale, è bene farlo, perché ti costringe a concentrarsi su come una particolare funzione effettivamente adattarsi quello che stai facendo (per dire, un gioco).

    Così buon gioco gli sviluppatori di fare ciò, naturalmente. Solo non in modo esplicito.

  7. 1

    @Runa, ancora una Volta, si prega di sottolineare la ‘D’, piuttosto che ‘T’. A livello di unità, i test sono un pensiero strumento per aiutarvi a capire che cosa si vuole e per auto il design del codice. Certamente a livello di unità, trovo che io alla fine con un detergente, codice robusto. Migliore è la qualità dei pezzi che ho messo nel sistema, il meglio che si incastrano con meno (ma non è nessun bug.

    Che non è la stessa cosa a tutti, come una sorta di test serio che giochi hanno bisogno.

    • Non si può veramente vedere come questo contrasta in alcun modo con quello che ho scritto. Pensando di testabilità durante la scrittura del codice è sempre buona, ma vi aiuterà ad affrontare solo un sottoinsieme delle esigenze di test di un ragionevolmente grande di dimensioni di gioco.
  8. 0

    TDD non è davvero un ‘normale’ approccio ovunque ma, come è ancora relativamente nuovo e non universalmente compreso o accettato di sicurezza. Quello non è di dire che alcuni negozi non funziona così, ma ora sto ancora sorpreso di sentire che qualcuno lo utilizzi a tutti, a questo punto.

    • Non ho intenzione di voto si / no o nulla, ma TDD è tanto parlato (a prescindere se si ha il vero merito o non) che sono sorpreso che il vostro “sorpreso di sentire che qualcuno lo utilizzi a tutti, a questo punto.”
    • TDD è praticamente standard in settori come quello aerospaziale o di imaging medico, e sono stati per almeno un decennio. Potrebbe non essere stato chiamato TDD, ma test di regressione automatico, copertura del codice, ecc.. c’erano molto prima che diventasse di moda.
    • Non nitpicky ma per il testing automatizzato non significa necessariamente che una persona fa del TDD.
    • m4bwav – la Gente parla di un sacco di cose, che non significa che effettivamente capire o la loro attuazione. Kena sorta dimostra il mio punto. Kena – test di Regressione e di copertura del codice != TDD.

Lascia un commento