Test di unità ignoranti - buoni e cattivi motivi quando e perché?

Question

Test di unità ignoranti - buoni e cattivi motivi quando e perché?

#1 da (14 voti)
#2 da (4 voti)

6

Recentemente ho iniziato un nuovo progetto per ri-implementare una parte fondamentale dell'automazione. Dato che è molto importante, lo faccio su TDDing in modo da poter testare vari scenari di base e cose che sappiamo che il vecchio sistema non funziona.

Nel fare questo, mi trovo a creare alcuni test "sandbox", che esercitano algoritmi "candidati" in completo isolamento, così posso scegliere quello che meglio soddisfa i requisiti. Ho anche creato alcuni test per capire perché altri test stanno fallendo, che di nuovo sono codificati in modo "sandbox" e non testano il codice di produzione attuale (hanno invece una semplificazione dell'ambiente di produzione che posso modificare fino a trova il problema / causa / soluzione). Nessuno di questi ha un valore costante per la regressione; una volta che scelgo un algoritmo, non potrò mai usare gli altri, e una volta che un test mostra il motivo per cui un altro test fallisce, posso correggere il test iniziale (o il suo codice di produzione esercitato) e verificare la correttezza, e non mi interessa più che l'altro test sia duro l'ambiente di esercizio codificato non funziona ancora.

Durante l'apprendimento del TDD mi è stato insegnato che non si è MAI eliminato un test di unità; anche se lo scopo originale del test è diventato irrilevante, il codice all'interno del test può essere utile ad altri sviluppatori come modello, oppure il test può essere rifattorizzato per altri scopi successivamente. Invece, se un test è diventato ridondante o irrilevante e non dovrebbe più essere eseguito, passato o fallito, dovrebbe essere ignorato.

Questa è la posizione "generalmente accettata" sull'ignorare i test? Questo ha il potenziale di abuso (ad es. "Non credo che pensi sia più importante, e fallisce, quindi lo ignorerò semplicemente")?

unit-testing

posta KeithS 13.02.2012 - 20:50

fonte

2 risposte

Leggi altre domande sui tag unit-testing

Parametro metodo di gruppo o parametro individuale? È una cattiva pratica usare lo stile in linea con il codice generato?

score 14 · Answer 1

once I pick an algorithm I may never use the others,

Falso per test ben scritti che utilizzano l'interfaccia dell'algoritmo.

Se i test eseguono i dettagli dell'implementazione e l'implementazione non è più applicabile, i test non vengono più applicati. Cancellali

and once a test shows why another test is failing, I can correct the initial test (or its exercised production code) and verify correctness, and I no longer care that the other test's hard-coded exercise environment still fails.

Um. Devi correggere "l'ambiente di esercizio hard-coded di altri test" in modo che sia significativo, utile e corretto.

Se un test è sbagliato (anche se ridondante) dovrebbe essere corretto in modo che sia corretto.

TDD significa che i test hanno ragione, prima di tutto. Alla fine il codice andrà bene.

"and it fails, so I'll just ignore it"

Questo non è un potenziale abuso. Questo è abuso.

Non puoi ignorare un test in errore. Se il test è sbagliato, deve essere risolto.

Rimuovere test che sembrano ridondanti è una perdita di tempo. Test aggiuntivi non fanno mai male a nessuno. In effetti, può scoprire errori super-sottili che superano una versione di un test fallendo un'altra versione di un test superficialmente simile. Ciò potrebbe indicare errori di progettazione in un'interfaccia più che un bug di implementazione.

score 4 · Answer 2

Preferirei che tutti i miei test passassero in un dato momento quando vengono eseguiti. Se un test fallisce e non c'è documentazione che spieghi perché si prevede che fallisca, allora non dovrebbe essere semplicemente ignorato. Qualsiasi altro sviluppatore che lavora con questi test sarà confuso poiché non sarà immediatamente a conoscenza del fatto che una modifica recente abbia influito sul risultato di eventuali test non riusciti.

Immagina di dover spiegare a un collega o manager perché alcuni test falliti devono essere "ignorati". Non penso che ti divertirai a spiegare loro perché questi fallimenti sono una cosa positiva e non devono essere affrontati.

Ricorda che stai testando il tuo codice per assicurarti la correttezza. I guasti dovrebbero sempre solo indicare che il codice testato non è corretto e l'errata non dovrebbe mai essere ignorata.