Devo metodi di test unitari ereditati dalla superclasse?

Question

Attualmente sto scrivendo un'implementazione di un driver JDBC ( sì, l'hai letto correttamente ) in modo TDD e mentre ho finito solo stub di classe a questo punto e solo alcune funzionalità minori, mi è appena venuto in mente che poiché Statement è una superclasse per PreparedStatement che è una superclasse per CallableStatement , cosa devo fare quando inizio davvero a scrivere test per le mie implementazioni di quelle classi, quale di queste dovrei fare:

1. Crea una suite di test per Statement e quindi estendi quella suite per test aggiuntivi per PreparedStatement e poi fai lo stesso per CallableStatement .
2. Testa ogni implementazione ignorando singolarmente i metodi ereditati dalle superclassi.
3. Testa rigorosamente ogni singolo metodo individualmente per ogni classe di implementazione; È possibile che alcuni metodi ereditati funzionino diversamente a seconda dell'implementazione. Una leggera variazione di questo sarebbe che testerei tutti quei metodi ereditati che l'implementazione utilizza.

Il numero due sembra il più naturale, ma per il motivo che ho messo al terzo non sono sicuro che sarebbe saggio farlo. Quindi, cosa tu pensi che dovrei fare?

Answer 1

In particolare non farei mai l'alternativa 1 (lasciando che la gerarchia di classi di test sia la stessa della gerarchia di classi effettiva) se ciò significa che eseguirai ripetutamente gli stessi test per ogni sottoclasse di test. Sono anche generalmente scettico riguardo alla sottoclasse di classi di test diverse dalla classe base di utilità generale.

Normalmente eseguo 1 test per ogni classe in una gerarchia, astratta o no. Quindi la classe base ha un test separato (di solito con una sottoclasse privata test-local che viene utilizzata per testarlo in modo specifico) e utilizzo la mia conoscenza delle sottoclassi per scrivere test adeguati per ogni sottoclasse. Riesco a vedere in copertura cosa manca ai test, quindi di solito non sono troppo formalizzato in anticipo.

Answer 2

" testa ogni singolo metodo individualmente per ogni classe di implementazione "

In particolare, l'incapacità di sovrascrivere correttamente un metodo di superclasse è un bug comune. L'autore della sottoclasse formula ipotesi sulla superclasse. La superclasse cambia e la sottoclasse ora è interrotta.

Answer 3

Fornisci test sufficienti per farti sentire a tuo agio, in base alla tua conoscenza dell'implementazione. Non considero i test unitari come test completamente black-box. Se sai che la classe base non chiama mai alcun metodo virtuale (o almeno nessuno che è stato ignorato), nota questo fatto ma non duplica efficacemente i test unitari che hai già.

I test unitari possono certamente essere portati all'estremo: vale sempre la pena bilanciare il valore che si ottiene da esso con lo sforzo che ti sta costando.

Answer 4

Con TDD, non dovresti mirare ai metodi di prova, ma al comportamento o alle capacità del tuo codice. Pertanto, quando si implementa una sottoclasse, è possibile limitare al test solo i comportamenti diversi dalla classe base. In caso di dubbi, scrivere un nuovo test.