Un punto debole del metodo TDD?

Question

Un punto debole del metodo TDD?

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

5

Questo è in sintesi il metodo TDD:

Scrivi un test
controlla se il test fallisce
scrivi il codice di produzione
esegui test

Penso che il TDD come presentato funzioni solo in circostanze ideali. Prenderò un semplice esempio:

Specification : Scrivi un programma che calcola la radice quadrata di un numero, l'utente deve inserire un numero. Se il numero è negativo, il programma dovrebbe visualizzare un errore e se il numero è positivo o zero il programma dovrebbe visualizzare il numero di cui è inserito il numero o il numero decimale il cui quadrato è il più vicino al numero inserito.

Scrittura test

class SquareRootTest {

   private SquareRoot squareRoot;

   public void testNegativeNumber() {    
      assertException(squareRoot.execute(-5);   
   }

   public void testIntegerSquareRoot() {
      assertEqual(squareRoot.execute(9),3);
   }

   public void testDecimalSquareRoot() {
     assertEqual(squareRoot.execute(3),1.732);
   }
}

avvia test non riuscito

scrittura del codice di produzione:

class SquareRoot {

 public double execute(Number number) {
     if(number < 0) 
         throw exception;
     if(number < 1)
         return squareRootLessThanOne(number);
      else
         return squareRootGreaterThanOne(numner);
   }

//private methods....

}

questo è quando scrivi un codice di produzione, trovo che devo trattare con numeri inferiori a uno in modo diverso da quelli maggiori di 1. Quindi devo aggiornare i miei test per riflettere questo.

Aggiornamento test

class SquareRootTest {

   public void testNegativeNumber() {    
       assertException(squareRoot.execute(-5));   
   }

   public void testIntegerSquareRoot() {
       assertEqual(squareRoot.execute(9),3);
   }

   public void testDecimalSquareRoot() {
      assertEqual(squareRoot.execute(3),1.732);
   }

   public void testNumberLowerThanOne() {
      assertEqual(squareRoot.execute(0.04),0.200);
   }
}

Se avessi trovato un singolo algoritmo per calcolare la radice quadrata, non avrei modificato i miei test.

Il metodo TDD si concentra esclusivamente sui test delle specifiche, tuttavia ci sono test derivati dall'implementazione, in particolare tutte le istruzioni condizionali e tutte le istruzioni controllate da loop dovrebbero normalmente essere testate. Questi casi di test non possono essere rilevati al momento della specifica.

La mia domanda: in che modo TDD si occuperà di questa situazione? o è efficacemente una debolezza del TDD?

tdd

posta Belin 07.05.2013 - 13:44

fonte

2 risposte

Leggi altre domande sui tag tdd

Il modo migliore per definire, avviare e interrompere i thread in C # Come evitare più chiamate a un'API REST? [chiuso]

score 20 · Answer 1

The TDD method focuses solely on tests from specifications

No. Non è così. TDD incoraggia l'aggiunta di test basati sulla tua implementazione. In ogni fase della tua implementazione stai cercando un test che fallirà. Aggiungi questo test e fallo passare.

Quindi nel tuo caso, quando hai trovato che i numeri meno di uno devono essere trattati in modo diverso, inizi ad aggiungere un test per quei numeri che hanno fallito la tua implementazione. Quindi aggiungerei meno di una versione.

score 14 · Answer 2

Un test alla volta. Dici che dovrebbe generare un'eccezione se hai un argomento negativo?

public double execute(Number number) {
    throw exception;
}

Ora passa il primo test.

Dici che dovrebbe restituire 3 se dato 9?

public double execute(Number number) {
    if (number.equals(9))
        return 3;
    throw exception;
}

Ora passa entrambi i test.

Ma sai che non hai finito. Sai che hai appena messo dei valori fittizi, una logica fittizia. Aggiungi test per guidarlo a una soluzione corretta e saprai quando è più semplice inserire la soluzione corretta piuttosto che aggiungere un altro ramo fittizio.

Credo che il problema che stai riscontrando nella comprensione di TDD sia il pensiero che tutti i test siano scritti in anticipo. Loro non sono. Scrivi uno, fallo passare. Scrivi quello successivo, fallo passare (senza interrompere il primo). Refactor quando verde. Che è TDD, non tradurre una specifica completa in test e poi farli passare.