Va bene scrivere test di unità "extra"?

6

La mia comprensione di come TDD dovrebbe funzionare è la scrittura di un test non funzionante per il prossimo bit di funzionalità che si desidera aggiungere a una funzione o oggetto, codice fino al passaggio del test e quindi scrittura del test successivo. È mai ok scrivere test che passano con il codice così com'è?

Un esempio di ciò è accaduto oggi. Stavo scrivendo una funzione che Manchester potrebbe codificare per un numero arbitrario di bit. Ho scritto test falliti per codificare un singolo bit e codificato fino a quando non è passato, quindi ho scritto un test non riuscito per passare due bit alla funzione e codificato fino a quando non è passato. Ma la soluzione che usavo per gestire due bit ha fatto funzionare il codice per un numero qualsiasi di bit. Perché passare un byte alla funzione sarà il suo uso più comune, ho aggiunto un test unitario per assicurarmi che funzionasse per 8 bit, cosa che in effetti è passata.

Ho violato i principi TDD? C'è qualcosa di sbagliato nell'aggiungere test ridondanti solo per la mia tranquillità? Capisco che parte del problema è che avrei potuto scrivere un test difettoso e non lo avrei mai saputo perché non ha fallito in primo luogo, ma non sono sicuro di quale sia l'alternativa.

    
posta samt1903 16.08.2014 - 07:26
fonte

2 risposte

8

Le ragioni principali per l'utilizzo di TDD sono di assicurarsi che ogni bit di codice che scrivi sia almeno minimamente esercitato dalla suite di test e che la tua API sia ben utilizzabile per il programmatore dell'applicazione.

Scrivere un test aggiuntivo per un caso che già passa non aumenta la copertura e non modifica ulteriormente l'API, quindi nessuno di questi motivi si applica - il test non aggiunge alcun valore sotto questi aspetti, ma certamente non nuoce neanche. Ci vuole solo del tempo per scrivere che potresti aver speso fare qualcos'altro.

Tuttavia, è perfettamente possibile avere algoritmi che funzionano su casi semplici e persino look come se fossero completamente generali, ma di fatto non lo sono, quindi non c'è nulla di sbagliato in linea di principio con l'aggiunta di un altro test case per N = 8. In un mondo perfetto potresti aver pensato subito a quel caso e aver scritto entrambi i test prima di codificare la soluzione, ma non importa molto se lo aggiungi successivamente: hai comunque soddisfatto tutti i principi che la gente vuole per il TDD.

(Ci sono quelli che richiedono che tu scrivi esattamente un caso di test e poi esattamente un bit di codice, e che ogni test prova esattamente una cosa, cioè che ogni difetto nella tua base di codice andrebbe in errore esattamente un test, ma non vedo alcun valore aggiunto in tale esagerata osservanza del ciclo.)

    
risposta data 16.08.2014 - 09:11
fonte
1

Se il test copre un comportamento che è prezioso e vuoi evitare le regressioni, allora è una buona idea scriverlo "dopo il fatto".

Immagina che qualcun altro abbia già scritto il codice senza test. Non ti starai chiedendo se sia una cattiva idea aggiungere test al codice esistente.

    
risposta data 16.08.2014 - 10:22
fonte

Leggi altre domande sui tag