Test unitari isolati e guasti a grana fine

3

Una delle ragioni spesso addotte per scrivere test di unità che deridono tutte le dipendenze e sono quindi completamente isolate è garantire che quando un bug esista, solo i test dell'unità per quel bug falliranno. (Ovviamente anche un test di integrazione potrebbe fallire). In questo modo puoi facilmente determinare dove si trova il bug.

Ma non capisco perché questa sia una proprietà utile. Se il mio codice stava subendo fallimenti spontanei, ho potuto capire perché è utile identificare prontamente il punto di errore. Ma se ho un test fallito o perché ho appena scritto il test o perché ho appena modificato il codice sotto test. In entrambi i casi, so già quale unità contiene un bug.

Che cosa è utile per garantire che un test fallisca solo a causa di bug nell'unità in prova? Non vedo come mi dia più precisione nell'identificare il bug di quanto non avessi già.

    
posta Winston Ewert 23.08.2014 - 19:21
fonte

2 risposte

1

But if I have a failing test its either because I just wrote the test or because I just modified the code under test. In either case, I already know which unit contains a bug.

Ma "il codice sotto test" non è solo il codice della classe / modulo testato, ma anche il codice eseguito dalle sue dipendenze.

Se ho

public TaxCalculator {
  public Currency getTaxAmount(Currency barePrice) {
     ...
  }

  public Currency getFinalPrize(Currency barePrize) {
     return barePrize.add(getTaxAmount(barePrize));
  }
}

e provo getFinalPrize senza il mocking getTaxAmount e ottengo un errore, quindi tutto quello che so è che c'è un errore in getFinalPrize o in getTaxAmount .

Certo, per una situazione così semplice vedresti che anche il test getTaxAmount è fallito e forse il link automatico fallirà entrambi. Ma se pensi a un bug in una classe che è ampiamente utilizzato e ricevi improvvisamente decine o centinaia di fallimenti di test, stabilire una relazione non sarebbe così facile.

    
risposta data 23.08.2014 - 19:35
fonte
1

Chi dà questa ragione? Lo considero un motivo debole, in effetti quasi inutile. Il punto di avere test unitari è quello di assicurare che i difetti rilevabili no siano nel codice sotto test. Quando la suite di test fallisce, sai che c'è almeno un difetto, quindi non puoi pubblicare il tuo codice base: non importa se esattamente un caso di test fallisce o più.

Chiaramente sarebbe bello poter leggere dal titolo del singolo test di errore esattamente quale sia il problema, ma ciò non accade mai nella pratica. Ci vuole uno sforzo eccessivo per sistemare le cose in modo che ogni test faccia effettivamente solo un bit di codice e nessun altro test faccia lo stesso, e questo sforzo non è quasi mai utile. È molto più importante che ogni percorso di codice sia almeno una volta che esattamente una volta . E se una modifica rompe più di un caso di test alla volta, di solito si indaga su uno di essi e si risolve il problema, a quel punto scompaiono anche gli altri errori - è piuttosto come la diagnostica del compilatore sotto questo aspetto: solo il primo errore è significativo, gli altri potrebbero essere spuri.

    
risposta data 24.08.2014 - 09:33
fonte

Leggi altre domande sui tag