¿La inyección de dependencia es esencial para las pruebas unitarias?

¿Es esencial el uso de la inyección de dependencia (DI) para las pruebas unitarias?

No puedo pensar en otra alternativa para aislar el código para que pueda probarse. Además, todos los ejemplos que he visto usan este patrón. ¿Es porque es la única opción viable o hay otras alternativas?

DI facilita mucho las pruebas unitarias. Pero aún puede escribir pruebas unitarias sin DI. Ya se han escrito muchas pruebas unitarias antes de que la DI se generalizara. (Por supuesto, algunas de estas técnicas utilizadas son idénticas o muy similares a la DI sin saber que tiene un nombre elegante :-)

Yo mismo he usado mucho, por ejemplo, interfaces y fábricas antes de aprender sobre DI. El nombre real de la clase de fábrica puede haberse leído de un archivo de configuración, o pasado al SUT como argumento.

Otro enfoque es usar singletons (o datos accesibles a nivel mundial en general). Sí, sé que no es recomendado por muchos (incluido yo mismo) en general. Aún así, puede ser viable en situaciones específicas, especialmente si el singleton contiene datos de configuración estáticos que no son específicos del caso de prueba, pero difieren entre la producción y el entorno de prueba. Por supuesto, tiene sus problemas conocidos, por lo que la DI es superior si puede usarla. Pero a menudo (por ejemplo, en sistemas heredados) no se puede.

Hablando de eso, Trabajar eficazmente con código heredado describe muchos trucos para obtener código heredado cubierto por pruebas. Muchos de estos no son agradables y no se consideran una solución a largo plazo. Pero le permiten crear las primeras pruebas unitarias valiosas para un sistema que de otro modo no sería comprobable ... lo que le permite comenzar a refactorizar, y eventualmente (entre otros) introducir DI.

El desacoplamiento es esencial para las pruebas unitarias. DI es una excelente manera de lograr el desacoplamiento.

Dependiendo de las tecnologías que esté utilizando, puede aislar dependencias sin usar DI. Por ejemplo, en el mundo .NET, Moles le permite aislar dependencias sin el patrón DI.

Dicho esto, creo que estos marcos de aislamiento están escritos y destinados a situaciones en su código con dependencias externas (sistema de archivos, base de datos, etc.). Es decir, el hecho de que uno pueda hacer esto no significa que deba hacerlo.

La inyección de dependencia permite pruebas unitarias, pero también permite modificar el comportamiento de un objeto sin alterar el código de ese objeto (principio abierto / cerrado). Por lo tanto, no se trata solo de un código comprobable, sino de un código flexible que resulta. En general, he descubierto que existe una gran correlación entre el código mantenible / flexible y el código comprobable.

No, la DI no es esencial para las pruebas unitarias, pero ayuda mucho.

Puede usar fábricas o localizadores y probar como lo haría con DI (solo que no es tan elegante y requeriría más configuración).

Además, Mock Objects sería importante en sistemas heredados donde muchas llamadas se delegan a funciones en lugar de dependencias. (Los objetos simulados también se pueden utilizar ampliamente en una configuración adecuada)

Puede haber configuraciones donde la prueba es casi imposible. Pero esto no se basa en si se usa o no la inyección de dependencia.

No , la inyección de dependencia no es esencial para las pruebas unitarias.

La inyección de dependencia ayuda si tiene una clase que necesita una instancia de clase dependiente para realizar un subprocesamiento. En lugar de DI, puede separar la lógica de un método comercial en una parte de recopilación de datos (que no es comprobable por unidad) y una parte de cálculo que puede probarse por unidad.

Ejemplo (usando DI) Esta implementación depende de Empleado, Cuenta, ...

 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;
     ...
 }

Después de la separación de la recopilación de datos y el cálculo:

 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 de cálculo se puede probar fácilmente sin inyección de dependencia.

• La inyección de dependencia no es esencial para las pruebas unitarias

• La inversión del control, por otro lado, es esencial cuando desea intercambiar una implementación por otra.

Sí, hay alternativas al uso de DI para el aislamiento.

Una alternativa es utilizar fábricas o un ServiceLocator que se puede configurar a partir de pruebas para devolver objetos simulados en lugar de objetos reales.

Otra es utilizar un marco de aislamiento adecuado o una herramienta de burla. Dichas herramientas existen para casi todos los lenguajes de programación modernos (para Java, C #, Ruby y Python, al menos). Pueden aislar una clase que se está probando de la implementación de otras clases / tipos, incluso cuando la clase probada instancia directamente sus dependencias.