TDD vs. produttività

Nel mio progetto attuale (un gioco, in C ++), ho deciso di utilizzare Test Driven Development al 100% durante lo sviluppo.

In termini di qualità del codice, questo è stato fantastico. Il mio codice non è mai stato così ben progettato o così privo di bug. Non mi arrabbio quando visualizzo il codice che ho scritto un anno fa all'inizio del progetto, e ho acquisito un senso molto migliore su come strutturare le cose, non solo per essere più facilmente testabile, ma per essere più semplice da implementare e utilizzare .

Tuttavia ... è passato un anno da quando ho iniziato il progetto. Certo, posso lavorarci solo nel mio tempo libero, ma TDD mi sta ancora rallentando considerevolmente rispetto a quello a cui sono abituato. Ho letto che la velocità di sviluppo più lenta migliora nel tempo, e sicuramente penso ai test molto più facilmente rispetto al passato, ma ci sono stato per un anno e sto ancora lavorando al ritmo di una lumaca.

Ogni volta che penso al prossimo passo che necessita di lavoro, devo fermarmi ogni volta e pensare a come scriverei un test per farlo, per permettermi di scrivere il codice reale. A volte rimango bloccato per ore, sapendo esattamente quale codice voglio scrivere, ma non sapendo come scomporlo abbastanza finemente da coprirlo completamente con i test. Altre volte, elaborerò rapidamente una dozzina di test e passerò un'ora a scrivere test per coprire un minuscolo pezzo di codice reale che altrimenti richiederebbe qualche minuto per scrivere.

Oppure, dopo aver terminato il 50 ° test per coprire una particolare entità nel gioco e tutti gli aspetti della sua creazione e utilizzo, guardo la mia lista di cose da fare e vedo la prossima entità da codificare, e rabbrividisco con orrore al pensiero di scrivere altri 50 test simili per implementarlo.

È arrivato al punto che, osservando i progressi dell'ultimo anno, sto pensando di abbandonare TDD per "finire il dannato progetto". Tuttavia, rinunciare alla qualità del codice che ne deriva non è qualcosa che non vedo l'ora. Temo che, se smetterò di scrivere test, abbandonerò l'abitudine di rendere il codice così modulare e testabile.

Sto forse facendo qualcosa di sbagliato per essere ancora così lento in questo? Esistono alternative che accelerano la produttività senza perdere completamente i benefici? TAD? Meno copertura del test? In che modo le altre persone sopravvivono al TDD senza uccidere tutta la produttività e la motivazione?

Vorrei iniziare ringraziandoti per condividere la tua esperienza e esprimere le tue preoccupazioni ... che devo dire non sono rare.

• Tempo / Produttività: scrivere test è più lento di non scrivere test. Se lo cerchi, sarei d'accordo. Tuttavia, se si esegue uno sforzo parallelo in cui si applica un approccio non TDD, è probabile che il tempo che impieghi nel codice esistente break-detect-debug-and-fix ti ponga in netto negativo. Per me, TDD è il più veloce che posso fare senza compromettere la mia sicurezza del codice. Se trovi elementi nel tuo metodo che non aggiungono valore, eliminali.
• Numero di test: se si codificano N cose, è necessario testare N cose. per parafrasare una delle righe di Kent Beck " Prova solo se vuoi che funzioni " .
• Rimanere bloccato per ore: lo faccio anche io (a volte e non> 20 minuti prima di interrompere la linea). È solo il tuo codice che ti dice che il design ha bisogno di un po 'di lavoro. Un test è solo un altro client per la tua classe SUT. Se un test trova difficoltà nell'utilizzare il tuo tipo, è probabile che lo siano anche i tuoi clienti di produzione.
• Test analoghi tedio: questo ha bisogno di un po 'più di contesto per poter scrivere un contro-argomento. Detto questo, fermati e pensa alla somiglianza. Riesci a guidare in qualche modo quei test? È possibile scrivere test su un tipo di base? Quindi è sufficiente eseguire lo stesso set di test per ogni derivazione. Ascolta i tuoi test. Sii il giusto tipo di pigro e vedi se riesci a trovare un modo per evitare la noia.
• Smettere di pensare a cosa devi fare dopo (il test / le specifiche) non è una brutta cosa. Al contrario, è raccomandato per costruire "la cosa giusta". Di solito se non riesco a pensare a come testarlo, di solito non riesco nemmeno a pensare all'implementazione. È una buona idea sopprimere le idee di implementazione fino ad arrivare lì .. forse una soluzione più semplice è oscurata da un design preventivo YAGNI.

E questo mi porta alla domanda finale: come posso migliorare? La mia (o An) risposta è Leggi, Rifletti ed Esercita.

ad es. di recente, tengo d'occhio

• se il mio ritmo riflette RG [Ref] RG [Ref] RG [Ref] o è RRRRGRRef.
• % di tempo trascorso nello stato Errore di compilazione / rosso.
• Sono bloccato in uno stato di build Red / Broken?

Non hai bisogno del 100% di copertura del test. Sii pragmatico.

TDD mi sta ancora rallentando considerevolmente

Questo è in realtà falso.

Senza TDD, trascorri alcune settimane a scrivere codice che funziona per lo più e trascorri l'anno successivo a "testare" e correggere molti (ma non tutti) i bug.

Con TDD, passi un anno a scrivere codice che funziona davvero. Quindi esegui il test di integrazione finale per alcune settimane.

Il tempo trascorso sarà probabilmente lo stesso. Il software TDD avrà una qualità sostanzialmente migliore.

Oppure, dopo aver terminato il 50 ° test per coprire una particolare entità nel gioco e tutti gli aspetti della sua creazione e utilizzo, guardo la mia lista di cose da fare e vedo la prossima entità da codificare, e rabbrividisco con orrore al pensiero di scrivere altri 50 test simili per implementarlo.

Questo mi fa chiedere quanto stai seguendo il passo "Refactor" di TDD.

Quando tutti i test vengono superati, è tempo di refactoring del codice e rimuovere la duplicazione. Mentre le persone di solito lo ricordano, a volte dimenticano che anche questo è il momento di riformattare i loro test , rimuovere la duplicazione e semplificare le cose.

Se hai due entità che si uniscono in una per consentire il riutilizzo del codice, prendi in considerazione anche l'unione dei loro test. Devi solo testare differenze incrementali nel tuo codice. Se non esegui regolarmente la manutenzione sui tuoi test, questi possono diventare rapidamente ingombranti.

Un paio di punti filosofici sul TDD che potrebbero essere utili:

• Quando non riesci a capire come scrivere un test, nonostante la lunga esperienza nella scrittura di test, è sicuramente un odore di codice . Il tuo codice è in qualche modo privo di modularità, il che rende difficile scrivere piccoli e semplici test.
• L'aggiunta di un po 'di codice è perfettamente accettabile quando si utilizza TDD. Scrivi il codice che desideri, per avere un'idea di come appare, quindi elimina il codice e inizia con i test.
• Vedo la pratica del TDD estremamente rigoroso come una forma di esercizio. Quando inizi, scrivi sicuramente un test prima ogni volta e scrivi il codice più semplice per far passare il test prima di proseguire. Tuttavia, questo non è necessario quando si diventa più a proprio agio con la pratica. Non ho un unit test per ogni singolo possibile percorso di codice che scrivo, ma per esperienza sono in grado di scegliere cosa deve essere testato con un unit test e cosa può essere coperto invece da test funzionali o di integrazione. Se pratichi TDD in modo rigoroso da un anno, immagino che anche tu sei vicino a questo punto.

EDIT: Sul tema della filosofia dei test unitari, penso che potrebbe essere interessante per te leggere: The Way of Testivus

E un punto più pratico, se non necessariamente molto utile, di:

• Citi C ++ come linguaggio di sviluppo. Ho praticato ampiamente TDD in Java, usando eccellenti librerie come JUnit e Mockito. Tuttavia, ho trovato TDD in C ++ molto frustrante a causa della mancanza di librerie (in particolare, framework di derisione) disponibili. Sebbene questo punto non ti aiuti molto nella tua situazione attuale, spero che tu lo prenda in considerazione prima di abbandonare del tutto il TDD.

Domanda molto interessante.

La cosa importante da notare è che il C ++ non è facilmente testabile e, in generale, il gioco è anche un pessimo candidato per TDD. Non è possibile verificare se OpenGL / DirectX disegna triangolo rosso con driver X e giallo con driver Y facilmente. Se il vettore normale della bump map non viene capovolto dopo la trasformazione dello shader. Né è possibile testare i problemi di ritaglio sulle versioni dei driver con precisioni diverse e così via. Il comportamento di disegno indefinito a causa di chiamate errate può anche essere testato solo con un'accurata revisione del codice e SDK a portata di mano. Anche il suono è un cattivo candidato. Il multithreading, che è di nuovo molto importante per i giochi, è praticamente inutile per i test unitari. Quindi è dura.

Fondamentalmente il gioco è un sacco di interfaccia grafica, suono e thread. La GUI, anche con componenti standard a cui è possibile inviare WM_, è difficile da testare.

Quindi ciò che puoi testare sono le classi di caricamento dei modelli, le classi di caricamento delle trame, le librerie di matrici e alcune di queste, che non sono un sacco di codice e, abbastanza spesso, non molto riutilizzabili, se è solo il tuo primo progetto. Inoltre, sono confezionati in formati proprietari, quindi non è molto probabile che l'input di terze parti possa differire molto, a meno che non rilasci strumenti di modding ecc.

Inoltre, non sono guru o evangelista TDD, quindi prendi tutto questo con un granello di sale.

Probabilmente scriverei alcuni test per i componenti principali (ad esempio la libreria di matrici, la libreria di immagini). Aggiungi un sacco di abort()input imprevisti in ogni funzione. E, soprattutto, concentrati sul codice resistente / resiliente che non si rompe facilmente.

Per quanto riguarda gli errori, l'uso intelligente di C ++, RAII e un buon design fanno molto per prevenirli.

Fondamentalmente hai molto da fare solo per coprire le basi se vuoi rilasciare il gioco. Non sono sicuro se TDD aiuterà.

Sono d'accordo con le altre risposte, ma voglio anche aggiungere un punto molto importante: i costi di refactoring !!

Con test unitari ben scritti, puoi tranquillamente riscrivere il tuo codice. Innanzitutto, test unitari ben scritti forniscono un'eccellente documentazione dell'intento del codice. In secondo luogo, eventuali effetti collaterali sfavorevoli del refactoring verranno rilevati nella suite di test esistente. Pertanto, hai garantito che le ipotesi del tuo vecchio codice sono vere anche per il tuo nuovo codice.

In che modo le altre persone sopravvivono al TDD senza uccidere tutta la produttività e la motivazione?

Questo è completamente diverso dalle mie esperienze. O sei incredibilmente intelligente e scrivi codice senza bug, (ad es. Con un errore) o non ti rendi conto che il tuo codice ha dei bug che impediscono il funzionamento del tuo programma, e quindi non sono effettivamente finiti.

TDD riguarda l'umiltà di sapere che tu (e io!) Commettiamo errori.

Per me il tempo di scrivere unittest è più che risparmiato in tempi di debug ridotti per i progetti che vengono eseguiti utilizzando TDD dall'inizio.

Se non commetti errori, forse TDD non è così importante per te come lo è per me!

Ho solo alcune osservazioni:

1. Sembra che tu stia provando a testare tutto . Probabilmente non dovresti, solo i casi ad alto rischio e limite di un particolare pezzo di codice / metodo. Sono abbastanza sicuro che la regola 80/20 si applica qui: spendi l'80% scrivendo test per l'ultimo 20% del tuo codice o casi che non sono coperti.

2. Dare priorità. Entra nello sviluppo di software agile e fai un elenco di ciò che devi veramente fare per rilasciarlo in un mese. Quindi rilasciare, proprio così. Questo ti farà pensare alla priorità delle funzionalità. Sì, sarebbe bello se il tuo personaggio potesse fare un backflip, ma ha valore commerciale ?

TDD è buono, ma solo se non miri alla copertura del test al 100%, e non lo è se ti impedisce di produrre valore commerciale effettivo (ovvero funzionalità, elementi che aggiungono qualcosa al tuo gioco).

Sì, la scrittura di test e codice potrebbe richiedere più tempo rispetto alla semplice scrittura di codice, ma la scrittura di codice e test unitari associati (utilizzando TDD) è molto più prevedibile della scrittura di codice e quindi del debug.

Il debug viene quasi eliminato quando si utilizza TDD, il che rende tutti i processi di sviluppo molto più prevedibili e, alla fine, probabilmente più veloci.

Refactoring costante: è impossibile eseguire qualsiasi refactoring serio senza una suite completa di test unitari. Il modo più efficiente per costruire quella rete di sicurezza basata su test unitari è durante TDD. Il codice ben refactored migliora significativamente la produttività complessiva del progettista / team che mantiene il codice.

Prendi in considerazione la possibilità di restringere l'ambito del tuo gioco e portalo dove qualcuno può giocarlo o lo rilasci. Mantenere i tuoi standard di prova senza dover aspettare troppo tempo per rilasciare il tuo gioco potrebbe essere una via di mezzo per mantenerti motivato. Il feedback dei tuoi utenti può offrire vantaggi a lungo termine e i tuoi test ti consentono di sentirti a tuo agio con le aggiunte e le modifiche.