Scrivere il codice minimo per superare un test unitario - senza barare!

Quando si esegue TDD e si scrive un unit test, come si fa a resistere all'impulso di "imbrogliare" quando si scrive la prima iterazione del codice di "implementazione" che si sta testando?

Ad esempio:
dobbiamo calcolare il fattoriale di un numero. Comincio con un unit test (usando MSTest) qualcosa del tipo:

[TestClass]
public class CalculateFactorialTests
{
    [TestMethod]
    public void CalculateFactorial_5_input_returns_120()
    {
        // Arrange
        var myMath = new MyMath();
        // Act
        long output = myMath.CalculateFactorial(5);
        // Assert
        Assert.AreEqual(120, output);
    }
}

Eseguo questo codice e non riesce poiché il CalculateFactorialmetodo non esiste nemmeno. Quindi, ora scrivo la prima iterazione del codice per implementare il metodo in prova, scrivendo il codice minimo richiesto per superare il test.

Il fatto è che sono continuamente tentato di scrivere quanto segue:

public class MyMath
{
    public long CalculateFactorial(long input)
    {
        return 120;
    }
}

Questo è, tecnicamente, corretto in quanto è davvero il codice minimo richiesto per far passare quel test specifico (diventa verde), anche se è chiaramente un "imbroglio" dal momento che in realtà non tenta nemmeno di svolgere la funzione di calcolo di un fattoriale. Naturalmente, ora la parte di refactoring diventa un esercizio di "scrittura della corretta funzionalità" piuttosto che un vero refactoring dell'implementazione. Ovviamente, l'aggiunta di test aggiuntivi con parametri diversi fallirà e forzerà un refactoring, ma devi iniziare con quel test.

Quindi, la mia domanda è: come si ottiene quell'equilibrio tra "scrivere il codice minimo per superare il test" pur mantenendolo funzionale e nello spirito di ciò che si sta effettivamente cercando di ottenere?

È perfettamente legittimo. Rosso, verde, refattore.

Il primo test ha superato.

Aggiungi il secondo test, con un nuovo input.

Ora diventa rapidamente verde, potresti aggiungere un if-else, che funziona benissimo. Passa, ma non hai ancora finito.

La terza parte di Red, Green, Refactor è la più importante. Refactor per rimuovere la duplicazione . Avrai duplicazioni nel tuo codice ora. Due istruzioni che restituiscono numeri interi. E l'unico modo per rimuovere quella duplicazione è codificare correttamente la funzione.

Non sto dicendo di non scriverlo correttamente la prima volta. Sto solo dicendo che non è barare se non lo fai.

Chiaramente è necessaria la comprensione dell'obiettivo finale e il raggiungimento di un algoritmo che soddisfi tale obiettivo.

TDD non è un proiettile magico per il design; devi ancora sapere come risolvere i problemi usando il codice e devi ancora sapere come farlo a un livello superiore a poche righe di codice per effettuare un test di prova.

Mi piace l'idea di TDD perché incoraggia un buon design; ti fa pensare a come puoi scrivere il tuo codice in modo che sia testabile, e in generale quella filosofia spingerà il codice verso una migliore progettazione complessiva. Ma devi ancora sapere come progettare una soluzione.

Non favorisco le filosofie riduzioniste del TDD che sostengono che puoi far crescere un'applicazione semplicemente scrivendo la minima quantità di codice per superare un test. Senza pensare all'architettura, questo non funzionerà e il tuo esempio lo dimostra.

Lo zio Bob Martin dice questo:

Se non stai eseguendo Test Driven Development, è molto difficile definirti un professionista. Jim Coplin mi ha chiamato sul tappeto per questo. Non gli piaceva, l'ho detto. In effetti, la sua posizione in questo momento è che Test Driven Development sta distruggendo le architetture perché le persone stanno scrivendo test per abbandonare qualsiasi altro tipo di pensiero e stanno facendo a pezzi le loro architetture nella folle corsa per far passare i test e ha un punto interessante, è un modo interessante di abusare del rituale e perdere l'intento dietro la disciplina.

se non stai pensando attraverso l'architettura, se invece stai ignorando l'architettura e mettendo insieme i test e facendoli superare, stai distruggendo la cosa che permetterà all'edificio di rimanere in piedi perché è la concentrazione sul struttura del sistema e solide decisioni di progettazione che aiutano il sistema a mantenere la sua integrità strutturale.

Non puoi semplicemente lanciare un sacco di test insieme e farli passare decennio dopo decennio dopo decennio e presumere che il tuo sistema sopravviverà. Non vogliamo evolvere noi stessi all'inferno. Quindi un buon sviluppatore guidato dai test è sempre consapevole di prendere decisioni sull'architettura, pensando sempre al quadro generale.

Un'ottima domanda ... e non sono d'accordo con quasi tutti tranne @Robert.

scrittura

return 120;

per una funzione fattoriale effettuare un test test è una perdita di tempo . Non è "barare", né segue letteralmente il refactor rosso-verde. E ' sbagliato .

Ecco perché:

• Calcola fattoriale è la funzione, non "restituisce una costante". "return 120" non è un calcolo.

• gli argomenti del "refactor" sono sbagliati; se si hanno due casi di test per 5 e 6, questo codice è ancora sbagliata, perché non sta calcolando un fattoriale a tutti :

  if (input == 5) { return 120; } //input=5 case
  else { return 720; }   //input=6 case
  

• se seguiamo letteralmente l' argomento 'refactor' , quando abbiamo 5 casi di test invochiamo YAGNI e implementiamo la funzione usando una tabella di ricerca:

  if (factorialDictionary.Contains(input)) {
      return factorialDictionary[input]; 
  }
  throw new Exception("Input failure");
  

Nessuno di questi sta effettivamente calcolando nulla, tu lo sei . E non è questo il compito!

Quando hai scritto solo un test unitario, l'implementazione su una riga ( return 120;) è legittima. Scrivere un ciclo calcolando il valore di 120 - sarebbe un imbroglio!

Tali semplici test iniziali sono un buon modo per individuare casi limite e prevenire errori una tantum. Cinque in realtà non è il valore di input con cui inizierei.

Una regola empirica che potrebbe essere utile qui è: zero, uno, molti, lotti . Zero e uno sono importanti casi limite per il fattoriale. Possono essere implementati con una linea. Il "molti" test case (es. 5!) Ti costringerebbe a scrivere un loop. Il caso di test "lotti" (1000 !?) potrebbe costringerti a implementare un algoritmo alternativo per gestire numeri molto grandi.

Finché hai solo un singolo test, il codice minimo necessario per superare il test è veramente return 120;e puoi facilmente mantenerlo per tutto il tempo in cui non hai più test.

Ciò consente di posticipare ulteriormente la progettazione fino a quando non si scrivono effettivamente i test che esercitano ALTRI valori di ritorno di questo metodo.

Ricorda che il test è la versione eseguibile della tua specifica, e se tutta quella specifica dice che f (6) = 120 allora si adatta perfettamente al conto.

Se sei in grado di "imbrogliare" in questo modo, suggerisce che i tuoi test unitari sono imperfetti.

Invece di testare il metodo fattoriale con un singolo valore, testare era un intervallo di valori. I test basati sui dati possono aiutare qui.

Visualizza i test unitari come una manifestazione dei requisiti: devono definire collettivamente il comportamento del metodo testato. (Questo è noto come sviluppo guidato dal comportamento - è il futuro ;-))

Quindi chiediti: se qualcuno dovesse cambiare l'implementazione in qualcosa di errato, i tuoi test passerebbero comunque o direbbero "aspetta un minuto!"?

Tenendo presente questo, se il tuo unico test era quello in questione, quindi tecnicamente l'implementazione corrispondente è corretta. Il problema viene quindi visualizzato come requisiti mal definiti.

Basta scrivere più test. Alla fine, sarebbe più breve scrivere

public long CalculateFactorial(long input)
{
    return input <= 1 ? 1 : CalculateFactorial(input-1)*input;
}

di

public long CalculateFactorial(long input)
{
    switch (input) {
       case 0: return 1;
       case 1: return 1;
       case 2: return 2;
       case 3: return 6;
       case 4: return 24;
       case 5: return 120;
    }
}

:-)

Scrivere test "cheat" è OK, per valori sufficientemente piccoli di "OK". Ma ricorda: il test unitario è completo solo quando tutti i test superano e non è possibile scrivere nuovi test che falliranno . Se vuoi davvero avere un metodo CalculateFactorial che contiene un sacco di istruzioni if (o anche meglio, una grande istruzione switch / case :-) puoi farlo, e dato che hai a che fare con un numero a precisione fissa il codice richiesto implementare questo è finito (anche se probabilmente piuttosto grande e brutto, e forse limitato dalle limitazioni del compilatore o del sistema sulla dimensione massima del codice di una procedura). A questo punto se davveroinsistere sul fatto che tutto lo sviluppo deve essere guidato da un unit test, è possibile scrivere un test che richiede al codice di calcolare il risultato in un tempo più breve di quello che può essere realizzato seguendo tutti i rami dell'istruzione if .

Fondamentalmente, TDD può aiutarti a scrivere codice che implementa correttamente i requisiti , ma non può costringerti a scrivere un buon codice. Dipende da te.

Condividi e divertiti.

Sono d'accordo al 100% con il suggerimento di Robert Harveys qui, non si tratta solo di superare i test, ma è necessario tenere presente anche l'obiettivo generale.

Come soluzione al tuo punto di vista di "è verificato che funzioni solo con un determinato set di input", proporrei di utilizzare test basati sui dati, come la teoria di xunit. Il potere alla base di questo concetto è che consente di creare facilmente le specifiche degli ingressi alle uscite.

Per i fattoriali, un test sarebbe simile al seguente:

    [Theory]
    [InlineData(0, 1)]
    [InlineData( 1, 1 )]
    [InlineData( 2, 2 )]
    [InlineData( 3, 6 )]
    [InlineData( 4, 24 )]
    public void Test_Factorial(int input, int expected)
    {
        int result = Factorial( input );
        Assert.Equal( result, expected);
    }

Potresti persino implementare un test-data fornire (che ritorna IEnumerable<Tuple<xxx>>) e codificare un invariante matematico, come la divisione ripetuta per n produrrà n-1).

Trovo che questo sia un modo molto potente di testare.

Se riesci ancora a imbrogliare, i test non sono sufficienti. Scrivi altri test! Per il tuo esempio, proverò ad aggiungere test con input 1, -1, -1000, 0, 10, 200.

Tuttavia, se ti impegni davvero a imbrogliare, puoi scrivere un infinito if-then. In questo caso, nulla potrebbe aiutare tranne la revisione del codice. Verrai presto catturato dal test di accettazione ( scritto da un'altra persona! )

Il problema con i test unitari è che talvolta i programmatori li considerano come un lavoro inutile. Il modo corretto di vederli è come uno strumento per rendere corretto il risultato del tuo lavoro. Quindi, se crei un if-then, sai inconsciamente che ci sono altri casi da considerare. Questo significa che devi scrivere un altro test. E così via e così via finché non ti rendi conto che il tradimento non funziona ed è meglio semplicemente codificare nel modo corretto. Se senti ancora che non hai finito, non sei finito.

Vorrei suggerire che la scelta del test non è il test migliore.

Vorrei iniziare con:

factorial (1) come primo test,

fattoriale (0) come il secondo

fattoriale (-ve) come il terzo

e poi continua con casi non banali

e finire con un caso di troppo pieno.