Molto probabilmente, sei arrivato alla tua cifra di 65 miliardi di test calcolando tutte le possibili combinazioni di input nel sistema in prova o calcolando la complessità ciclomatica e assumendo che un test debba essere scritto per ciascuno di questi percorsi di esecuzione unici.
Non è così che vengono scritti test reali, perché, come hanno indicato altri poster e commentatori, la potenza tecnica richiesta per eseguire 65 miliardii test sono sconcertanti. Sarebbe come scrivere un test che eserciti un metodo per aggiungere due numeri interi collegando ogni possibile permutazione di due valori a 32 bit e controllando il risultato. È una follia assoluta. Devi tracciare la linea e identificare un sottoinsieme di tutti i possibili casi di test, che tra loro assicurerebbero che il sistema si comporti come previsto in tutta la gamma di input. Per esempio. si verifica l'aggiunta di alcuni numeri "ordinari", si verificano alcuni scenari con numeri negativi, si verificano limiti tecnici come scenari di overflow e si verifica qualsiasi scenario che dovrebbe causare errori. Come accennato, questi vari tipi di test esercitano "classi di equivalenza"; ti consentono di prelevare un campione rappresentativo dei possibili input, insieme a eventuali "valori anomali" noti,
Considera uno dei kata in codice di base, il generatore di numeri romani. Il compito, da eseguire usando le tecniche TDD in stile "dojo", è scrivere una funzione che possa accettare qualsiasi numero compreso tra 1 e 3000 e produrre il numero romano corretto per quel valore numerico.
Non risolvi questo problema scrivendo 3000 unit test, uno alla volta, e superandoli a turno. Questa è follia; l'esercizio normalmente dura tra una e due ore e saresti lì per giorni a testare ogni singolo valore. Invece, diventi intelligente. Si inizia con il caso base più semplice (1 == "I"), si implementa quello usando una strategia di "codice minimo" ( return "I";), quindi si cerca come il codice che si comporterà in modo errato in un altro scenario previsto (2 == " II "). Risciacqua e ripeti; molto probabilmente, hai sostituito la tua implementazione iniziale con qualcosa che ripete il carattere "I" tutte le volte che è necessario (come return new String('I',number);). Questo ovviamente supererà un test per III, quindi non ti preoccupare; invece scrivi il test per 4 == "IV", che sai che l'attuale implementazione ha vinto "
Oppure, in uno stile più analitico, si esamina ogni decisione condizionale che viene presa dal codice (o deve essere) e si scrive un test progettato per inserire il codice per ogni possibile risultato di ogni decisione. Se hai 5 istruzioni if (ognuna con un ramo vero e falso), ognuna completamente indipendente dall'altra, codifichi 10 test, non 32. Ogni test sarà progettato per affermare due cose su una particolare decisione possibile; prima che sia presa la decisione corretta, e poi che il codice inserito dato quella condizione sia corretto. Lei non codificare un test per ogni possibile permutazione delle decisioni indipendenti. Se le decisioni dipendono, allora devi testarne di più in combinazione, ma ci sono meno combinazioni di questo tipo perché alcune decisioni vengono prese solo quando un'altra decisione ha avuto un risultato particolare.