Preferiresti rendere le cose private interne / pubbliche per i test o utilizzare un qualche tipo di hack come PrivateObject?

Sono piuttosto un principiante nel test del codice, ed era una assertputtana prima. Una cosa che mi preoccupa nei test unitari è che spesso è necessario che tu faccia public(o almeno internal) campi che privatealtrimenti sarebbero stati , per sbloccarli readonly, invece fare privatemetodi protected virtual, ecc ...

Recentemente ho scoperto che puoi evitarlo usando cose come la classe PrivateObject per accedere a qualsiasi cosa in un oggetto tramite la riflessione. Ma questo rende i tuoi test meno gestibili (le cose falliranno durante l'esecuzione piuttosto che in fase di compilazione, verrà interrotta da una semplice ridenominazione, è più difficile eseguire il debug ...). Qual è la tua opinione su questo ? Quali sono le migliori pratiche nei test unitari riguardanti le restrizioni di accesso?

modifica: considera ad esempio che hai una classe con una cache in un file su disco e nei tuoi test vuoi invece scrivere in memoria.

Non dovresti mai e poi mai

crea public(o almeno internal) campi che privatealtrimenti sarebbero stati , per sbloccarli readonly, invece fai privatemetodiprotected virtual

Soprattutto il non-lettura di un campo può rendere mutevole un oggetto immutabile, e questo sarebbe un disastro.

I tuoi test dovrebbero considerare i tuoi oggetti come scatole nere ( Wikipedia ), nel senso che dovrebbero riguardare solo l'interfaccia pubblica degli oggetti, non i dettagli della loro implementazione.

Se un oggetto non può essere sufficientemente testato utilizzando la sua interfaccia pubblica, è necessario trovare modi per fornire estensioni formali e utili alla sua interfaccia che facilitino il test. Ad esempio, un sistema di registrazione con solo una coppia di metodi Register / Deregister potrebbe forse beneficiare di un metodo IsRegistered anche se non è necessario per l'applicazione a portata di mano; tuttavia, è un'estensione formale e utile dell'interfaccia e, per inciso, accetterà i test.

L'importante è che cambiare l'implementazione dell'oggetto non dovrebbe richiedere di cambiare il test unitario. In teoria dovresti essere in grado di scrivere il test unitario una volta, quindi chiedere a più programmatori di codificare più implementazioni completamente diverse dell'oggetto da testare per lavorare con il test unitario.

In C # è possibile utilizzare InternalsVisibleToAttributeper consentire all'assembly di test di vedere le internalclassi nell'assembly che si sta testando. Sembra che tu lo sappia già.

Nella maggior parte dei casi sono interessato solo a testare l'API pubblica del mio assembly. In un caso in cui voglio fare un test in white box di alcune unità, sposto il codice in una internalclasse e lo trasformo in un publicmetodo di quella classe. Quindi posso codificare un test unitario per quella classe.

Questo si presta bene all'iniezione di dipendenza e al modello di strategia. Puoi astrarre il metodo in un'interfaccia, iniettare l'interfaccia nel costruttore del tuo oggetto genitore e testare che il genitore deleghi in modo appropriato. Quindi è possibile verificare che l'oggetto figlio si comporti in modo appropriato. Questo rende tutto più modulare.

Nella mia esperienza, è meglio non esporre gli interni della tua classe appositamente per il test. Anche se questo può sembrare per facilitare la scrittura del test. Il test è il primo client della tua classe, quindi se è difficile testare la tua classe attraverso la sua interfaccia pubblica, probabilmente sarà difficile usare la tua classe anche in altri posti.

Quanto è facile testare la classe attraverso la sua API pubblica è un feedback su quanto sarà facile usare la classe. Pensa ai test parzialmente come un modo per prototipare l'uso della tua classe.

Prova a considerare perché il tuo test deve rilevare qualcosa sulla classe che non è disponibile tramite l'API pubblica. Forse la tua classe sta facendo troppo e deve invece essere scomposta in un gruppo di classi cooperanti? Quindi puoi prendere in giro alcune delle classi collaboranti per capire cosa sta facendo la classe sottoposta a test.

Prova ad applicare il principio di inversione di dipendenza e introduce interfacce tra le tue classi che puoi prendere in giro nei tuoi test. È possibile fornire i collaboratori al test utilizzando l' inversione del controllo .

Considera anche l'applicazione del principio "non chiedere" per aiutare a strutturare la tua interfaccia di classe in un modo robusto, liberamente accoppiato, in cui sono esposte le giuste informazioni e il resto nascosto.

Personalmente preferisco lasciare il codice che sto testando il più puro possibile e se il codice di test ha bisogno di hack (e in c ++ cattivi puntatori ecc.) Sono felice di farlo.

La visibilità del tuo codice non ha nulla a che fare con i tuoi test unitari!

Rendi i tuoi metodi privati ​​non allo scopo di nasconderli dai test e non li rendi pubblici da esporre per i test, giusto? Questa è la tua implementazione che è essenziale qui, non i test - quei server come prova del tuo codice, ma non sono il tuo codice .

Esistono molti modi per consentire l'accesso a metodi e proprietà nascosti (privati ​​o interni). Molti framework di test e IDE (ad esempio Visual Studio) ti supportano qui generando tutto il necessario per l'accesso, devi solo creare i tuoi casi di test. Quindi, perché preoccuparsi? Meglio mantenere il codice pulito e ordinato.