Come scrivere i test delle unità quando una correzione eseguirà molti test non riusciti?

Naviga le tue risposte
6

Ho due casi di test per testare una correzione al codice che utilizza criteri errati per la selezione di oggetti da una raccolta:

  1. Dato un oggetto nella raccolta che corrisponde ai criteri errati, assicurarsi che nessun oggetto venga restituito.
  2. Dati due oggetti nella raccolta, con quello successivo che corrisponde ai criteri errati, assicurati che l'oggetto precedente sia retratto.

Al momento, entrambi questi test falliranno.

Il problema è che, non appena avrò fatto la correzione, entrambi i test passeranno.

Va bene? Pensavo che avessimo bisogno di un singolo test dell'unità fallito prima di scrivere il codice. Non ho sentito che è ok avere più test unitari guasti prima di scrivere il codice.

    
posta John Saunders 28.12.2011 - 20:32
fonte

4 risposte

11

I thought we needed a single failing unit test before writing the code. I haven't heard it's ok to have multiple failing unit tests before writing code.

Questo è per scrivere nuove funzionalità, non per correggere bug e solo se vuoi praticare il TDD ultraortodosso.

In secondo luogo, una suite di test ideale sarebbe quella in cui qualsiasi errore causa il fallimento di un solo test, poiché ciò rende più facile individuare dove si verifica il bug. Ma questo è un ideale a cui si può aspirare ma che difficilmente raggiungono, e va bene. Cerca di rendere la tua unità test ortogonale se possibile, ma non preoccuparti se non puoi farlo tutto il tempo.

    
risposta data 28.12.2011 - 20:52
fonte
18

No, il punto della suite di test è che (per quanto ne sei in grado) copre ogni cosa immaginabile che le modifiche al codice potrebbero interrompersi. Non è così importante se uno o due test falliscono - il punto è che il cambiamento ha rotto qualcosa, e non può essere permesso prima che passi i test all . Non vi è assolutamente alcun punto di andare a contorsioni e provare a fare la correzione in due passaggi separati, solo per fissare esattamente un test per commit - è solo uno sforzo extra, e sfido chiunque a spiegarmi cosa ti compra.

    
risposta data 28.12.2011 - 20:38
fonte
6

Non esiste una regola che dice che devi eseguire solo un singolo passaggio di prova alla volta.

Di solito non scrivi troppi test prima di alcun codice, ma puoi farlo.

Pensa a loro come alle tue specifiche.

Ecco dei tutorial video davvero fantastici su TDD:

Funq: serie screencast su come costruire un contenitore DI usando TDD

    
risposta data 28.12.2011 - 20:44
fonte
1

Nei nostri casi di test cerchiamo di scriverli in 3 sezioni (se del caso)

  1. Configurazione
  2. Esecuzione test
  3. Asserzione

A volte potrebbe mancare una sezione, ma in generale coprono la maggior parte dei casi di test.

Nel tuo caso è perfettamente OK se alcuni test falliscono se la funzione non funziona - la cosa principale sarà capire la differenza e la somiglianza (che cosa è diverso è testato e perché i test stanno fallendo insieme). Come soluzione abbiamo scelto una convenzione di denominazione di test appropriata:

MethodBeingTested_ParametersOrTestCriteria_ExpectedResult()

Quindi i tuoi due test verrebbero identificati come 

Method1_1BadObject_ReturnsNoObjects()
Method1_1BadObjectAnd1GoodObject_ReturnsGoodObject()

So che usare i trattini bassi è una decisione difficile ma funziona perfettamente per noi. Puoi semplicemente dare uno sguardo al test fallito e identificare cosa si aspettava e che cosa stava fallendo.

Se entrambi falliscono, è chiaro che Method1 è il motivo.

    
risposta data 28.12.2011 - 23:41
fonte

Leggi altre domande sui tag

Perché i generatori di codice utilizzano sempre identificatori pienamente qualificati? L'argomento o il parametro sono considerati più appropriati per una funzione / parametro argomento / parametro?