Dove prendi in giro - le dipendenze immediate, o fai crescere i confini ...?

Question

Quindi, sono abbastanza nuovo sia per i test unitari che per i derisione in C # e .NET; Sto usando rispettivamente xUnit.net e Rhino Mocks. Sono un convertito e mi sto concentrando sulla scrittura di specifiche comportamentali, credo, invece di essere puramente TDD. Bah, semantica; Voglio che una rete di sicurezza automatizzata funzioni sopra, in sostanza.

Un pensiero però mi ha colpito. Ottengo la programmazione contro le interfacce e i vantaggi per quanto riguarda la suddivisione delle dipendenze vanno lì. Venduto. Tuttavia, nella mia suite di verifica del comportamento (aka test unitari ;-)), sto affermando il comportamento un'interfaccia alla volta. Come in, un'implementazione di un'interfaccia alla volta, con tutte le sue dipendenze derise e le aspettative impostate.

L'approccio sembra essere che se verifichiamo che una classe si comporta come dovrebbe contro le sue dipendenze collaborative, e a sua volta si affida a ciascuna di quelle dipendenze collaborative per aver firmato lo stesso contratto di qualità, siamo d'oro. Sembra abbastanza ragionevole.

Torna al pensiero, però. C'è qualche valore nei test di semi-integrazione, in cui un'apparecchiatura di test sta affermando contro un'unità di implementazioni concrete che sono collegate insieme e stiamo testando il suo comportamento interno contro dipendenze derise? L'ho appena riletto e penso che probabilmente avrei potuto esprimerlo meglio. Ovviamente, ci sarà una certa quantità di "bene, se ti aggiunge valore, continua a farlo", suppongo - ma qualcun altro ha pensato di farlo, e ne ha tratto beneficio superando i costi?

Answer 1

La tua domanda è stata discussa per anni e può anche essere riformulata come "cos'è un'unità"?

Non esiste una legge di unit test che dice che è necessario testare ciascuna classe in modo isolato. Tuttavia, per essere mantenibili, vuoi davvero che i test debbano cambiare solo quando cambia il comportamento che testano. In questo modo è spesso ragionevole usare versioni concrete di collaboratori stretti e falsi per quelli più distanti.

L'unico posto in cui uso assolutamente i falsi di un tipo o di un altro è seguire Regole di unit test .

Answer 2

Non vedo valore nei test di integrazione che collegano semplicemente insieme classi interne completamente testabili.

Mi sembra che il valore nei test di integrazione sia il punto in cui tocca la piattaforma o le interfacce esterne, vale a dire i contratti che non è possibile testare l'unità.