Strategia di test unitario per chiamate di metodo stratificate (o derivate)

Question

Strategia di test unitario per chiamate di metodo stratificate (o derivate)

#1 da (2 voti)
#2 da (0 voti)

3

Perdona il titolo: ha bisogno di lavoro. Sto lottando per trovare un inglese migliore per esprimere il mio problema. Modifiche consigliate.

Esempio per descrivere il mio problema:

Metodo Checker

Ho un metodo di controllo degli argomenti chiamato public static void StringArgs.checkIndexAndCount(String, int, int) . Dato una stringa, un indice e un conteggio, conferma che la stringa non è nullo e l'indice & i conteggi sono ragionevoli. Le eccezioni non selezionate (runtime) vengono utilizzate per segnalare errori. C'è una batteria di test unitari scritti per verificare tutti gli angoli di questo metodo.

Metodo stratificato (o derivato)

Il metodo di controllo è chiamato da altri metodi, come public static String removeByIndexAndCount(String, int, int) . La prima riga di questo metodo controlla gli argomenti chiamando il checker sopra.

Strategia test unità

Quando scrivo i test unitari per il metodo secondo / stratificato / derivato, come faccio a tenere conto dell'insieme esistente di test unitari per il metodo di controllo? Sembra violare i principi di duplicazione / copia-incolla per aggiungere nuovamente gli stessi test di unità (leggermente modificati) dal metodo di controllo al secondo metodo.

Si prega di avvisare.

Il mio codice è Java, ma non penso che sia particolarmente rilevante, poiché questo stesso problema potrebbe verificarsi in qualsiasi lingua.

unit-testing

posta kevinarpe 27.07.2013 - 11:05

fonte

2 risposte

Leggi altre domande sui tag unit-testing

LuaJit FFI e nascondere i dettagli di implementazione C Gerarchia parallela di classe / interfaccia con il motivo di progettazione della facciata?

score 2 · Answer 1

Non è necessario testare tutti gli scenari per il metodo Checker durante il test di X . Tutto quello che devi veramente fare nel test di X è assicurarti che effettivamente usi il metodo Checker , quindi puoi davvero rinunciare a tutti quegli scenari di input di test a X .

Il modo per farlo è allo stesso modo che assicurerei che gli Assert che ho codificato che sono essenziali per la validazione del contratto per un metodo, siano ancora presenti: codifica un singolo test che dovrebbe attivare l'assert e controllare che EAssertionFailed (o qualunque altra cosa) è davvero sollevata.

Per lo scenario che significherebbe codificare un singolo test per il metodo X per garantire che in realtà richiami il metodo 'Checker'. Ad esempio, utilizzando l'input di test per il quale il Checker genererebbe un'eccezione.

Naturalmente un programmatore intelligente potrebbe ostacolare questo controllo controllando questo input in X e restituendo la stessa eccezione. Ma devi tracciare la linea da qualche parte. Non stai proteggendo dagli hacker ma da qualcuno che dimentica di usare Checker e / o di rimuovere inavvertitamente la chiamata a Checker .

score 0 · Answer 2

In generale, non mi concentrerei troppo sulla riduzione della ripetizione nei test unitari. È necessario testare il modulo di livello inferiore in modo che possa essere riutilizzato in modo affidabile ed è necessario testare quello di livello superiore nel caso in cui lo si cambi per interrompere l'uso del modulo di livello inferiore. Scrivere questi test è un po 'laborioso, ma una volta scritta, la ripetizione non causerà lo stesso tipo di problemi di qualità del codice come il codice di produzione ripetuto nella mia esperienza.