Come gestire le modifiche che richiedono ulteriori test mentre si lavora su un altro test?

Question

Come gestire le modifiche che richiedono ulteriori test mentre si lavora su un altro test?

#1 da (3 voti)

3

TDD significa testare prima di iniziare a scrivere codice di produzione. Quindi inizio a scrivere un test per MyClass chiamato MyClassTest . Fallisce e comincio a implementare la funzionalità desiderata in MyClass .

Durante la fase di implementazione di MyClass ho riscontrato che le modifiche su un'altra classe (ad esempio MyClassUtils ) sono necessarie per essere eseguite. MyClassUtils ha una sua classe di test. A seguito di TDD dovrei testare prima di implementare qualsiasi nuova funzionalità. Quindi dovrei interrompere il lavoro su MyClass per il primo test e implementare prima i metodi necessari in MyClassUtilsTest ? Oppure è meglio tracciare in qualche modo (ad esempio scrivendolo su carta, TODO nel codice, ecc.) I metodi di test che devono essere aggiunti e ignorare "testare prima"?

Spesso incontro questo problema e non sono sicuro di quale sia il modo migliore per affrontarlo. La prima possibilità porta a commit più grandi e incasinati con cambiamenti in almeno quattro classi e periodi di tempo più lunghi senza commit. Il secondo non tiene conto del primo principio del test, porta a un arretrato di test non implementati e riduce la copertura del codice.

Come ci si comporta? Sono grato per ogni consiglio. :)

tdd unit-testing task-organization

posta kms 11.11.2011 - 10:30

fonte

1 risposta

Leggi altre domande sui tag tdd unit-testing task-organization

Approccio di progettazione per l'elaborazione continua e sensibile ai tempi dei record API REST con file come risorse?

score 3 · Accepted Answer

IMO questa domanda riguarda più l'organizzazione del proprio lavoro in modo efficiente rispetto a TDD.

Di solito mi sforzo di organizzare i miei compiti per mantenermi efficiente e concentrato. Quindi, se trovo altri compiti da fare mentre lavoro su un'attività specifica, di solito faccio le note TODO a me stesso (nel codice o su un pezzo di carta) e mantengo l'attenzione sul mio compito originale. Una volta che l'ho eseguito, prendo il prossimo TODO fino a quando non ho finito.

Tuttavia, se è necessaria la nuova attività per implementare correttamente quella originale, vedo due approcci (a parte il "big ball commit" che descrivi):

parcheggiare l'attività principale, implementare e impegnare la nuova sotto-attività (ma solo quella!), quindi tornare all'attività principale, o
implementa l'attività principale che deride il comportamento previsto di MyClassUtils nei test unitari, esegui il commit, quindi prosegui con l'attività più recente.

Di solito preferisco il primo approccio (dal basso verso l'alto), in quanto è più semplice. Nota che, in un buon progetto, non ci sono dipendenze cicliche, ovvero MyClass dipende da MyClassUtils o viceversa, ma non entrambi. Questo garantisce che esiste un ordine bottom-up per implementare e commettere tutte le modifiche una alla volta senza interrompere la compilazione in qualsiasi momento.

Nota anche che se trascorro abbastanza tempo sulla progettazione prima di iniziare a scrivere codice, posso quasi sempre rilevare in anticipo che avrei bisogno di modificare / estendere MyClassUtils , così posso iniziare subito con quell'attività. Certo, sono un essere umano e faccio omissioni ogni tanto (o i requisiti possono cambiare a metà strada, ecc.), Quindi a volte tali passaggi laterali diventano necessari.