TDD. Quando puoi andare avanti?

Question

Quando si esegue TDD , come dire " sono sufficienti test per questa classe / funzione " ;?

vale a dire. quando potresti dire di aver completato il test di tutti i casi limite?

Answer 1

Con Test Driven Development, dovrai scrivere un test prima di scrivere il codice da testare. Una volta che hai scritto il codice e il test ha superato, è tempo di scrivere un altro test. Se segui correttamente TDD, hai scritto abbastanza test una volta che hai rielaborato tutto il necessario.

Per quanto riguarda i casi limite, prendiamo un esempio come la convalida di un parametro in un metodo. Prima di aggiungere il parametro al tuo codice, crei dei test che verificano che il codice gestirà correttamente ogni caso. Quindi è possibile aggiungere il parametro e la logica associata e assicurarsi che i test vengano superati. Se pensi a più casi limite, puoi aggiungere più test.

Facendolo un passo alla volta, non dovrai preoccuparti dei casi limite quando hai finito di scrivere il tuo codice, perché avrai già scritto i test per tutti. Certo, c'è sempre un errore umano e potresti perdere qualcosa ... Quando si verifica questa situazione, è il momento di aggiungere un altro test e quindi correggere il codice.

Answer 2

Il consiglio di Kent Beck è di scrivere test fino a quando la paura non si trasforma in noia. Cioè, fino a quando non hai più paura che qualcosa si rompa, supponendo che inizi con un livello adeguato di paura.

Answer 3

Ad un certo livello, è una sensazione viscerale di

  

" Sono fiducioso che i test colpiranno tutti i problemi a cui riesco a pensare   ora "?

Su un altro livello, hai già una serie di requisiti utente o di sistema che devono essere soddisfatti, in modo da poterti fermare qui.

Mentre uso la copertura del codice per dirmi se non ho seguito il mio processo TDD e per trovare il codice che può essere rimosso, non considero la copertura del codice come un modo utile per sapere quando interrompere. La copertura del codice potrebbe essere del 100%, ma se hai dimenticato di includere un requisito, beh, allora non hai davvero finito, vero?

Forse un malinteso su TDD è che devi sapere tutto in anticipo per testare. Questo è fuorviante perché i test che risultano dal processo TDD sono come una scia di pangrattato. Sai cosa è stato testato in passato e ti può guidare fino a un certo punto, ma non ti dirà cosa fare dopo.

Penso che TDD possa essere pensato come un processo evolutivo. Cioè, inizi con il tuo progetto iniziale ed è una serie di test. Man mano che il tuo codice viene danneggiato nella produzione, aggiungi altri test e il codice che li fa passare. Ogni volta che aggiungi un test qui e un test lì, stai anche facendo TDD e non costa molto. Non sapevi che esistessero quei casi quando hai scritto la tua prima serie di test, ma ora hai acquisito le conoscenze e puoi verificare la presenza di questi problemi con il semplice tocco di un pulsante. Questo è il grande potere del TDD e uno dei motivi per cui lo sostengo così tanto.

Answer 4

Bene, quando non riesci a pensare ad altri casi di fallimento che non funzionano come previsto.

Parte del TDD è mantenere un elenco di cose che vuoi implementare e problemi con la tua attuale implementazione ... quindi quando quella lista si esaurisce, essenzialmente hai finito ....

E ricorda, puoi sempre tornare indietro e aggiungere test quando scopri bug o nuovi problemi con l'implementazione.

Answer 5

quel buon senso, non c'è una risposta perfetta. L'obiettivo del TDD è rimuovere la paura, se ti senti sicuro di averlo provato abbastanza bene, continua ...

Non dimenticare che se in un secondo momento trovi un bug, scrivi prima un test per riprodurre il bug, quindi correggilo, così impedirai modifiche future per romperlo di nuovo!

Alcune persone si lamentano quando non hanno l'X percento di copertura .... alcuni test sono inutili e la copertura del 100% non significa che testate tutto ciò che può far decifrare il vostro codice, solo il fatto che non si romperà per il come l'hai usato!

Answer 6

Un test è un modo per descrivere con precisione qualcosa che desideri. L'aggiunta di un test espande il ambito di ciò che si desidera o aggiunge dettagli di ciò che si desidera.

Se non riesci a pensare a qualcos'altro che desideri o a qualsiasi perfezionamento di ciò che desideri, passa a qualcos'altro. Puoi sempre tornare più tardi.

Answer 7

I test in TDD riguardano la specifica , in realtà possono essere un sostituto per una specifica. In TDD, i test non riguardano la copertura del codice. Assicurano che il codice copra le specifiche, perché il codice fallirà un test se non copre le specifiche. Qualsiasi codice aggiuntivo che hai non ha importanza.

Quindi hai abbastanza test quando i test sembrano descrivere tutte le aspettative che tu o gli stakeholder hai.

Answer 8

forse mi sono perso qualcosa da qualche parte nel mondo Agile / XP, ma la mia comprensione del processo è stata che lo sviluppatore e il cliente hanno specificato i test come parte della funzionalità . Ciò consente ai casi di test di sostituire la documentazione di requisiti più formali, aiuta a identificare i casi d'uso per la funzione, ecc. Quindi hai finito i test e la codifica quando tutti questi test superano ... più eventuali altri casi limite che pensi lungo la strada

Answer 9

Alberto Savoia dice che " se tutti i test passano, è probabile che i test siano non abbastanza buono " ;. Penso che sia un buon modo di pensare ai test: chiedi se stai eseguendo casi limite, passa alcuni parametri imprevisti e così via. Un buon modo per migliorare la qualità dei test è lavorare con una coppia, specialmente un tester, e ottenere assistenza su più casi di test. L'abbinamento con i tester è buono perché hanno un diverso punto di vista.

Ovviamente, potresti usare alcuni strumenti per fare test di mutazione e ottenere più sicurezza da i tuoi test. Ho usato Jester e ha migliorato sia i miei test sia il modo in cui li ho scritti. Valuta di usare qualcosa di simile.

Cordiali saluti

Answer 10

Teoricamente dovresti coprire tutte le possibili combinazioni di input e testare che l'output sia corretto ma a volte non ne vale la pena.

Answer 11

Molti degli altri commenti hanno colpito l'unghia sulla testa. Ti senti sicuro del codice che hai scritto durante la copertura del test? Man mano che il codice si evolve, i test lo coprono ancora adeguatamente? I test acquisiscono il comportamento e la funzionalità previsti per il componente in prova?

Deve esserci un mezzo felice. Man mano che si aggiungono sempre più casi di test, i test potrebbero diventare fragili poiché ciò che è considerato un caso limite cambia continuamente. Seguire molti dei suggerimenti precedenti può essere molto utile per ottenere tutto ciò che si può pensare in anticipo e quindi aggiungere nuovi test man mano che il software cresce. Questo tipo di coltivazione biologica può aiutare i tuoi test a crescere senza tutto lo sforzo iniziale.

Non mentirò ma spesso divento pigro quando torno a scrivere test aggiuntivi. Potrei mancare quella proprietà che contiene il codice 0 o il costruttore predefinito che non mi interessa. A volte non essere completamente anali sul processo può farti risparmiare tempo n aree meno critiche (il mito della copertura del codice al 100%).

Devi ricordare che l'obiettivo finale è quello di ottenere un prodotto di prim'ordine fuori dalla porta e non ucciderti test. Se hai la sensazione che ti manchi qualcosa, allora hai molte possibilità e devi aggiungere altri test.

Buona fortuna e buona programmazione.

Answer 12

Puoi sempre utilizzare uno strumento di copertura dei test come EMMA ( http://emma.sourceforge.net/) o il suo plug-in Eclipse EclEmma ( http://www.eclemma.org/ ) o simili. Alcuni sviluppatori ritengono che la copertura del test al 100% sia un obiettivo meritevole; altri non sono d'accordo.

Answer 13

Cerca solo di trovare ogni modo per evitare che qualcosa fallisca. Valori null, valori fuori portata, ecc. Una volta che non riesci a trovare facilmente nulla, continua con qualcos'altro.

Se lungo la strada trovi mai un nuovo bug o ti viene in mente un modo, aggiungi il test.

Non si tratta di copertura del codice. Questa è una metrica pericolosa, perché il codice è "coperto". molto prima che sia "ben testato".