Come definire i dettagli di implementazione?

Question

Come definire i dettagli di implementazione?

#1 da (5 voti)

4

Nel nostro progetto, un assembly combina la logica per il contenitore IoC, gli interni del progetto e il livello di comunicazione. La versione corrente si è evoluta per avere solo classi interne negli assembly addin.

Il mio problema principale con questo approccio è che il punto di ingresso è disponibile solo sul contenitore IoC. Non è possibile utilizzare nient'altro che reflection per inizializzare l'assembly.

Tutto ciò che sta dietro l'interfaccia IoC è definito come dettaglio dell'implementazione e quindi non è destinato ad usi esterni. È risaputo che non dovresti testare i dettagli dell'implementazione (come i metodi privati e interni), perché dovrebbero essere testati attraverso l'interfaccia pubblica. È anche risaputo che i test non devono utilizzare il contenitore IoC per configurare i SUT, poiché ciò comporterebbe troppe dipendenze. Quindi utilizziamo l'attributo InternalsVisibleTo per rendere visibili gli interni ai nostri gruppi di test e testare i cosiddetti dettagli di implementazione.

Ho riconosciuto che un problema potrebbe essere la confusione tra le diverse preoccupazioni in quell'assemblea, cambiando questo renderebbe questa discussione inutile, perché le classi devono essere definite pubbliche. Ignorare le mie preoccupazioni con questo, non è la necessità di testare una classe sufficiente per renderlo pubblico, gli usi di InternalsVisibleTo sembra non intenzionale e un po '"hacky". L'approccio per testare solo contro il contenitore IoC pubblicamente disponibile è troppo costoso e comporterebbe test dello stile di integrazione.

I professionisti dell'uso di internals sono, che gli usi sono ben noti e non devono essere implementati come dovrebbe essere un metodo pubblico (documentazione, completezza, versioning, ...).

Esiste una soluzione, per non testare gli interni, ma mantenere i loro vantaggi rispetto alle classi pubbliche, o dobbiamo ridefinire quali sono i dettagli di un'implementazione.

unit-testing

posta dwonisch 25.06.2012 - 17:02

fonte

1 risposta

Leggi altre domande sui tag unit-testing

Il database di un'applicazione Web deve essere considerato un attore? Approccio al lavoro con molti programmatori su un modulo / funzione

score 5 · Accepted Answer

It is well known that you should not test implementation detail (such as private and internal methods), because they should be tested through the public interface. It is also well known, that your tests should not use the IoC-Container to setup the SUTs, because that would result in too much dependencies.

Capisco questo punto di vista, ma capisco anche che, in definitiva, si tratta di fare le cose. ™ Quando la cerimonia delle migliori pratiche inizia a interferire con la tua capacità di fare le cose, è tempo di fare un passo indietro e valuta le tue ipotesi.

Lasciatemi affermare equivocamente che io collaudo sempre i miei metodi privati e interni. Perché non dovrei? Un test unitario mi dà la sicurezza che il metodo si comporta come mi aspetto. La mia unità di testing framework fa questo, non ereditando dalla mia classe (motivo per cui alcuni framework di testing richiedono che i tuoi metodi siano virtuali), ma creando una classe proxy che riflette sulla mia classe reale per eseguire quei metodi.

So we are using the InternalsVisibleTo-Attribute to make internals visible to our test assemblies and test the so called implementation details.

Questo è ciò che dovrebbe fare. Se le tue migliori pratiche ti dicono che non puoi testare i tuoi interni, getta le migliori pratiche.

Puoi, e dovresti, testare ancora i tuoi metodi pubblici, ma tenerli in una zona separata in modo che tu possa identificarli in modo specifico (generalmente questi test corrispondono ai requisiti, quindi puoi usarli per dimostrare che i requisiti sono soddisfatti).