L'iniezione di dipendenza è essenziale per i test unitari?

L'uso dell'iniezione di dipendenza (DI) è essenziale per i test unitari?

Non riesco a pensare a un'altra alternativa per isolare il codice in modo che possa essere testato. Inoltre, tutti gli esempi che ho mai visto usano questo modello. È perché è l'unica opzione praticabile o ci sono altre alternative?

DI semplifica notevolmente i test unitari. Ma puoi ancora scrivere unit test senza DI. Molti test unitari sono già stati scritti prima che il DI diventasse diffuso. (Certo, alcune di queste tecniche usate identiche o molto simili a DI senza sapere che ha un nome di fantasia :-)

Io stesso ho usato ad esempio interfacce e fabbriche molto prima di conoscere DI. Il nome della classe di fabbrica effettiva potrebbe essere stato letto da un file di configurazione o passato al SUT come argomento.

Un altro approccio consiste nell'utilizzare singleton (o dati accessibili a livello globale in generale). Sì, lo so che non è raccomandato da molti (incluso me stesso) in generale. Tuttavia, può essere praticabile in situazioni specifiche, specialmente se il singleton contiene dati di configurazione statici che non sono specifici del caso di prova, ma differiscono tra ambiente di produzione e di prova. Ovviamente ha i suoi problemi noti, quindi DI è superiore se puoi usarlo. Ma spesso (ad esempio nei sistemi legacy) non puoi.

A proposito, lavorare in modo efficace con il codice legacy descrive molti trucchi per ottenere il codice legacy coperto dai test. Molti di questi non sono carini e non sono intesi come una soluzione a lungo termine. Ma ti consentono di creare i primi preziosi test unitari su un sistema altrimenti non verificabile ... che ti consente di iniziare il refactoring e infine (tra gli altri) introdurre DI.

Il disaccoppiamento è essenziale per i test unitari. DI è un ottimo modo per ottenere il disaccoppiamento.

A seconda delle tecnologie in uso, è possibile isolare le dipendenze senza utilizzare DI. Ad esempio, nel mondo .NET, Moles consente di isolare le dipendenze senza il modello DI.

Detto questo, credo che questi quadri di isolamento siano scritti e destinati a situazioni nel tuo codice con dipendenze esterne (filesystem, database, ecc.). Cioè, il fatto che uno possa fare questo non significa che dovrebbe farlo.

L'iniezione di dipendenza consente il testing di unità, ma consente anche la modifica del comportamento di un oggetto senza alterare il codice di quell'oggetto (principio aperto / chiuso). Quindi, non è solo il codice verificabile, ma il codice flessibile che ne risulta. Ho generalmente scoperto che esiste una forte correlazione tra codice gestibile / flessibile e codice verificabile.

No, DI non è essenziale per i test unitari, ma aiuta molto.

Puoi usare le fabbriche o i localizzatori e testare come faresti con DI (ma non altrettanto elegante e richiederebbe una maggiore configurazione).

Inoltre, Mock Objects sarebbe importante nei sistemi legacy in cui molte chiamate sono delegate a funzioni anziché a dipendenze. (Gli oggetti finti possono anche essere ampiamente utilizzati anche in una configurazione corretta)

Ci possono essere configurazioni in cui il test è quasi impossibile. Ma ciò non si basa sul fatto che venga utilizzata o meno l'iniezione di dipendenza.

No , l'iniezione di dipendenza non è essenziale per i test unitari.

L'iniezione di dipendenza aiuta se si dispone di una classe che necessita di un'istanza di classe dipendente per eseguire una subelaborazione. Invece di DI è possibile separare la logica di un metodo di business in una parte di raccolta dati (che non è testabile dall'unità) e una parte di calcolo che può essere testata dall'unità.

Esempio (utilizzando DI) Questa implementazione dipende da Dipendente, Account, ...

 bool hasPermissionToTransferMoney(Employee employee, Account from, Account to, Money amount)
 {
     if (amount > 100 && employee.isStudent())
        return false;
     if (to.getOwner().getFamiliyName() == employee.getFamilyName() && ...
        return false; // cannot transfer money to himself;
     ...
 }

Dopo la separazione dei dati raccolti e il calcolo:

 bool hasPermissionToTransferMoney(Employee employee, Account from, Account to, Money amount)
 {
     return hasPermissionToTransferMoney(employee.isStudent(), employee.getFamilyName(), to.getOwner().getFamilyName(), ...);
 }

 // the actual permission calculation
 static bool hasPermissionToTransferMoney(boolean isStudent, string employeeFamilyName, string receiverFamilyName, ...)
     if (amount > 100 && isStudent)
        return false;
     if (receiverFamilyName == employeeFamiliyName && ...
        return false; // cannot transfer money to himself
     ...
 }

La parte di calcolo può essere facilmente testata senza iniezione di dipendenza.

• L'iniezione di dipendenza non è essenziale per i test unitari

• L'inversione del controllo invece è essenziale quando si desidera scambiare un'implementazione con un'altra.

Sì, ci sono alternative all'uso di DI per l'isolamento.

Un'alternativa è quella di utilizzare le fabbriche o un ServiceLocator che può essere configurato dai test per restituire oggetti finti invece di quelli reali.

Un altro è usare una struttura di isolamento o uno strumento di derisione adatti. Tali strumenti esistono per quasi tutti i moderni linguaggi di programmazione (almeno per Java, C #, Ruby e Python). Possono isolare una classe in fase di test dall'implementazione di altre classi / tipi, anche quando la classe testata istanzia direttamente le sue dipendenze.