Progettazione di un robusto test dell'unità: test della stessa logica in molti modi diversi?

Question

Nella progettazione di test di unità, è molto facile cadere nella trappola di chiamare solo la logica di implementazione.

Ad esempio, se si verifica un array di int che dovrebbe essere tutti due più alti dell'altro (2, 4, 6, 8, ecc.), È davvero sufficiente ottenere il valore restituito dal metodo e affermare che questo modello è il caso?

Mi manca qualcosa? Sembra che un metodo di test di una singola unità debba essere reso più robusto testando la stessa aspettativa in diversi modi. Quindi l'aspettativa di cui sopra può essere asserita controllando che l'aumento di due stia accadendo, ma anche il prossimo numero è divisibile per 2. O è solo una logica ridondante?

Quindi, in breve, un'unità dovrebbe testare l'aspettativa in diversi modi? Per esempio, se volessi provare che i miei pantaloni mi si adattano, potrei/potrei misurare la lunghezza, metterla vicino alla mia gamba e vedere il confronto, ecc. È questo il tipo di logica necessaria per il test delle unità?

Grazie

Answer 1

il test di unità dovrebbe controllare tutte le tue supposizioni . Se lo fai in 1 test o più test è una preferenza personale.

Nell'esempio sopra riportato, erano presenti due diversi presupposti: (1) Ogni valore dovrebbe aumentare di 2. (2) Tutti i valori dovrebbero essere pari.

Dovrebbe (-8, -6, -4, -2) passare/fallire?

Ricordare, assicurarsi che il codice non funzioni quando è necessario, ma è altrettanto importante, se non più importante, quindi assicurarsi che passi quando è previsto.

Answer 2

Se si affermi che il vostro array contiene 2,4,6,8 - allora la logica di prova potrebbe essere viziata in quanto il test sarebbe passata se appena restituito un array con quegli elementi, ma non con Ad esempio, 6,8,10,12. È necessario verificare che il calcolo sia corretto. Quindi è necessario testarlo con più array, in questo caso particolare.

trovo che assicurandosi che il test ha esito negativo, poi fare il passo di prova, nel vero spirito del TDD, aiuta a scovare ciò che il test è corretto ...

Answer 3

La matrice che si sta testando deve essere generata in una sorta di logica. Non è meglio testare questa logica per garantire che l'array risultante soddisfi sempre le tue esigenze?

Answer 4

Ad esempio, se testare array di int che dovrebbe essere tutti due superiore rispetto all'altra (2, 4, 6, 8, ecc), è è davvero sufficiente per ottenere il ritorno valore il metodo e asserire che questo modello è il caso?

Forse hai bisogno di pensare un po 'di più su come la funzione verrebbe utilizzata. Sarà usato con numeri molto grandi? Se è così, potresti provare alcuni test con numeri molto grandi. Sarà usato con numeri negativi?

Mi manca qualcosa? Sembra che come un metodo di prova di una singola unità ha bisogno di per essere reso più robusto testando lo stesso aspettativa in diversi modi.Quindi l'aspettativa sopra può essere asserita verificando l'aumento di due è accadendo ma anche il numero successivo è divisibile per 2. O è solo questa logica ridondante ridondante? Logica ridondante?

Hmm ... beh 1,3,5,9 sarebbe superare la prova assertEachValueIncrementsByTwo, ma non sarebbe superare il test assertValuesDivisibleByTwo. Importa che siano divisibili per 2? Se è così, allora dovresti davvero testarlo. Se no, allora è un test ridondante inutile.

Dovresti provare a trovare più di 1 test per i tuoi metodi, ma i test ridondanti a scopo di ulteriori test non ti aiuteranno. Aggiungere il test assertValuesDivisibleByTwo quando ciò non è realmente necessario confonderà gli sviluppatori successivi che stanno cercando di modificare il codice.

Se non riesci a pensare ad altri test, prova a scrivere una funzione di input casuale che genererà 100 array di test casuali ogni volta che esegui i test. Sareste sorpresi di quanti errori sfuggono al radar quando controllate solo uno o due set di input.

Answer 5

Consiglierei più test. Se è necessario modificare il comportamento che si desidera avere il minor numero possibile di test da modificare. Questo rende anche più facile scoprire qual è il problema. Se la tua esecuzione è veramente assente e ottieni [1,3,4,5], il tuo test fallirà, ma per la prima cosa testerai solo un errore quando ci sono effettivamente due problemi diversi.

Provare a denominare i test. Se non riesci a dire con un chiaro nome di metodo, quello che stai testando rompe il test.

testEntriesStepByTwo 

testEntriesAllEven 

Inoltre, non dimenticare i casi limite. La lista vuota probabilmente passerà 'ogni voce è 2 in più rispetto al precedente' uno e 'tutte le voci sono anche' test, ma dovrebbe?