Modificatori di accesso di classe alle implementazioni testate

Naviga le tue risposte
1

Supponiamo che tu stia scrivendo un'interfaccia che si suppone sia la tua API pubblica, chiamiamola Session . L'implementazione è chiamata SessionImpl e verrà inserita dal tuo framework DI.

Sono bloccato a pensare all'accesso di classe per questa classe SessionImpl , se deve essere limitato al suo pacchetto (poiché l'API pubblica è l'interfaccia) ma non è in grado di testarlo da un progetto di test diverso, o rendilo pubblico e testalo.

La terza opzione verrebbe testata attraverso la sua interfaccia rendendo il DI utilizzare una fabbrica e chiamando la fabbrica dal test.

Qual è l'approccio corretto per mantenere un semplice codice gestibile?

    
posta Christopher Francisco 27.01.2016 - 22:58
fonte

1 risposta

2

Sì, se le implementazioni di sessione devono fornire lo stesso identico comportamento, avrebbe senso testare solo attraverso l'interfaccia implementata.

Tuttavia, se l'implementazione viene utilizzata solo attraverso l'interfaccia, non importa tutto ciò che ha metodi pubblici, al di fuori di esso? Nulla o nessuno dovrebbe accedere direttamente alla classe, tranne forse per i test che sono.

In .NET è possibile impostare un attributo assembly (InternalsVisibleTo) per consentire l'accesso ai membri interni tramite white-listing di un assembly (test). Qualcosa in questo senso, a seconda dell'ambiente, potrebbe funzionare anche.

Personalmente evito di inventare qualcosa di più complicato -oppure- se ho bisogno di aprire molte cose per testarlo potrebbe essere un'indicazione che un'altra classe sta cercando di uscire, ha bisogno di refactoring.

    
risposta data 28.01.2016 - 23:37
fonte

Leggi altre domande sui tag

La classe EntityBase o DomainBase viola l'LSP? Il design del compilatore impedisce la sovrascrittura del registro