Unit test su un progetto di grandi dimensioni con pochi componenti accessibili pubblicamente [duplicato]

Question

Unit test su un progetto di grandi dimensioni con pochi componenti accessibili pubblicamente [duplicato]

#1 da (2 voti)

3

Sto chiedendo di C #, ma probabilmente si applica anche alla maggior parte delle altre lingue.

Immagina di avere un progetto con molte logiche complesse, suddiviso in molti piccoli componenti. Diciamo che, tra le altre cose, contiene un ComplexProjectFacade con un singolo metodo che accetta alcuni parametri e restituisce un valore - e questo è l'unico componente che dovrebbe essere pubblico.

Ma la logica eseguita all'interno di quello che viene chiamato da quel singolo metodo è molto complessa e testare direttamente su ComplexProjectFacade non dà abbastanza certezza che tutto funzioni correttamente. Cosa dovrei fare in questo caso?

Metti i test unitari nello stesso progetto?
Rendi pubblicamente accessibili gli altri componenti solo per motivi di prova?
O forse è già sbagliato rendere i componenti interni? Forse dovrebbe essere accessibile dall'esterno?

access-modifiers unit-testing c#

posta Lasooch 03.03.2016 - 09:44

fonte

1 risposta

Leggi altre domande sui tag access-modifiers unit-testing c#

Come abbinare i corsi con i requisiti Il mix di builder e factory è una buona idea?

score 2 · Accepted Answer

Estrai la tua logica incapsulata in classi più piccole. Continuate a farlo finché non ottenete classi che aderiscono al principio SRP e ne avete una e una sola responsabilità. Scrivi test su quelle classi per verificare che eseguano la piccola responsabilità che hanno correttamente. Componi le tue classi più grandi da queste classi piccole, finché non hai l' ComplexProjectFacade che è composto da classi più piccole e così via.

In questo modo, crei classi piccole, mirate e facili da capire. Il fatto che abbiano metodi pubblici e possano quindi essere testati è un felice effetto collaterale dal fatto che ora hai un codice che è facile da capire . Ogni volta che sento qualcuno discutere sull'opportunità di rendere pubbliche classi o metodi puramente a scopo di test, cerco di far loro capire che stanno anche aderendo più chiaramente ai principi che portano a un codice migliore (es. SOLID ).

Il modo in cui lo fai al di là di questo è più legato alle preferenze personali:

Mettere i test accanto al codice nello stesso assembly inquina il codice rilasciato con i test. Saranno nella stessa DLL che aumenta la dimensione e così via. Probabilmente non vuoi rilasciare il tuo codice di test compilato con la tua applicazione, ma se non hai problemi con questo, è un approccio valido. Richiede comunque che ogni classe sia contrassegnata come Interna
Mantenere pubbliche le classi significa che l'interfaccia esposta della DLL diventa più complessa. Gli utenti che desiderano utilizzare la DLL vedranno una vasta gamma di classi e potrebbe non essere immediatamente evidente quale classe utilizzare per eseguire qualcosa. Un uso corretto degli spazi dei nomi potrebbe impedirlo, in quanto è possibile limitare lo spazio dei nomi di root alla facciata e mettere tutte le altre classi in spazi dei nomi (sotto) separati, rendendo più ovvio ciò che gli utenti devono osservare.
InternalsVisibleTo ti permette di mantenere tutte le tue piccole classi interne all'assemblaggio, limitando l'interfaccia esposta della tua DLL a cose che intendevi davvero aver esposto, ma richiede di mantenere tutte le classi interne e ti limita a dover ricompilare il tuo libreria con un nuovo attributo InternalsVisibleTo se si desidera aggiungere un nuovo assieme di test.