Voglio imparare come scrivere le prove per un pezzo di logica come test di unità. Ora non sono interessato a nessun framework o linguaggio specifico, volevo solo sapere come posso imparare a scrivere coppie input-output che coprono tutto il dominio di input possibile?
Ehi, tu mi puoi suggerire alcune strategie più simili ad Andrés suggerite come partizione all'equivalenza o alcuni libri in cui posso leggere questo?
Nulla è infallibile, e il caso generale di "come faccio a sapere che sto testando ogni scenario rilevante?" è "non puoi saperlo", ma ci sono approcci che tentano di sistematizzare la copertura dei casi di test rilevanti.
Con Partizionamento delle equazioni , si tenta di definire una relazione di equivalenza tra gruppi di dati di input, quindi testare solo un esempio di ogni relazione di equivalenza. Ad esempio, possibili raggruppamenti di interi di input potrebbero essere (a seconda dell'algoritmo in esame, ovviamente), "negativo", "zero" e "positivo".
Un'altra tecnica è Boundary Value Testing , dove si selezionano valori estremi o limite nell'intervallo di possibili input .
Ancora un'altra tecnica di test è, invece di scrivere ogni scenario a mano, selezionando una proprietà del proprio algoritmo e dicendo a un framework di test di verificarlo generando casi di test casuali per questo. Framework come QuickCheck o ScalaCheck tenteranno di trovare controesempi che infrangono la tua proprietà, nel qual caso ti diranno qualcosa come "I provato con l'input -1 e la tua proprietà non è riuscita ".
Tutte queste tecniche hanno limitazioni, ma sono buone linee guida durante la scrittura dei test.
Supponendo di avere una funzione pura, IE che non si basa su nessuno stato interno tra una chiamata e l'altra, si vorrebbe generare qualcosa come tabella di verità . Come @KilianFoth osserva nella sua risposta, questo è generalmente poco pratico per qualcosa di interessante. Dal momento in cui passi in qualcosa come un intero hai un enorme set di input, e con una stringa diventa effettivamente infinito.
In queste situazioni l'obiettivo è trovare casi utili che implichino che l'intera gamma funzioni senza verificarla esaustivamente. Ad esempio, non conoscendo il contenuto della funzione che potresti provare, il valore minimo, -100.000.000, -1, 0, 1, 100.000.000 e il valore massimo impostato come input per vedere cosa succede. Per un argomento di stringa arbitrario proverai un input come null, "", "a", "La volpe marrone veloce salta sul cane pigro", "! @ # $% ^ & ** () {} |: "< > [] \; ',. /?' ~" e "dz שࣚ" (unicode per quelli di voi che guardano solo i blocchi).
Questo sarebbe tutto considerato test della scatola nera in cui non guardi la funzione. Nella maggior parte delle situazioni software è possibile guardare il software e provare a progettare un input da guidare in tutti i casi scritti all'interno della funzione. Se c'è un caso speciale che accade solo se l'argomento intero è 3, assicurati che 3 renda l'elenco degli input testati.
Di solito, non puoi.
Se il compito che si sta programmando è abbastanza grande da rendere più facile scrivere un programma per computer che farlo a mano, allora il numero di possibili coppie di input / output è probabilmente troppo grande per essere testato in modo esaustivo.
Ma scrivere un caso di test contro ogni istanza di un errore precedentemente rilevato va molto lontano dal codice che gestisce correttamente tutti i casi rilevanti.
Leggi altre domande sui tag tdd unit-testing programming-practices