Inyección de dependencias en las pruebas

Question

Normalmente, cuando se utiliza la inyección de dependencia, las pruebas de unidad (y otras) son responsables de crear/burlarse de las dependencias del sistema bajo prueba e inyectarlas.

Sin embargo, a veces la prueba en sí tiene dependencias o necesita inyectar dependencias en el SUT que no puede crear. Por ejemplo, cuando se prueban clases que interactúan con una base de datos, la prueba necesita conocer cadenas de conexión y nombres de catálogo, etc., que no pueden codificarse rígidamente ya que no son necesariamente los mismos para todos los que ejecutan la prueba.

Entonces, ¿cómo recomendaría una prueba para averiguar esta configuración? ¿Algunos marcos de prueba estilo xUnit proporcionan una forma de proporcionar dependencias a un dispositivo de prueba? Si la clase de prueba tiene propiedades estáticas, ¿se completa antes de ejecutar todas las pruebas? ¿Debería la prueba ignorar las prácticas de DI y simplemente ir y obtener las dependencias de algún lugar global? ¿Otras sugerencias?

Answer 1

Cuando se está utilizando el marco de pruebas unitarias que hacer pruebas de integración, que en realidad no tienen un DI o un problema de la unidad de pruebas.

Lo que tiene son pruebas de integración que aprovechan el marco de pruebas de unidades de alta potencia.

Como son pruebas de integración, son diferentes en tipo de las pruebas unitarias. El "stand-alone-ness" realmente ya no cuenta.

La mejor forma de obtener ajustes de prueba de integración que varían de un usuario a otro es obtenerlos de la misma manera que la aplicación final. Si estás trabajando en Java, es posible que tengas un archivo de propiedades. En Python, tenemos archivos especiales de configuración de Django para las pruebas de integración.

Answer 2

Existe un principio para pruebas totalmente automatizadas: debe poder extraer todo el código fuente del repositorio de control de origen y simplemente ejecutar las pruebas.

Dado que el entorno (máquina) tiene la base de instalación correcta (es decir, compilador, marco de prueba, motor de base de datos si es relevante, etc.) las pruebas son responsables de configurar su dispositivo antes de ejecutar los casos de prueba.

Esto significa que para las bases de datos, las pruebas deben

1. crear la base de datos en cuestión
2. ejecutar sus pruebas
3. borrar la base de datos de nuevo después del último caso de prueba

Si, por alguna razón no puede hacer eso, lo único que puede hacer es tener un archivo de configuración en su sistema de control de origen que contenga entradas específicas de la máquina para todas las máquinas en sus pruebas invironment; p.ej. para la máquina Tst1 la cadena de conexión tiene un valor, pero para Tst2 es otra.

Esto puede ponerse feo rápidamente, por lo que es mucho más fácil hacer que las pruebas sean responsables de la configuración y desmontaje del dispositivo, porque eso significa que simplemente pueden usar valores codificados o valores generados in situ.

Esto realmente no tiene nada que ver con DI ...

Answer 3

DI peleas con dependecies complejidad, mientras que las pruebas unitarias deben ser mayoría de las veces muy simple. La prueba unitaria típica examinaría un aspecto aislado de una clase aislada. En lugar de todas sus dependencias, crea burlas y (normalmente) las inyecta a través del constructor CUT (Class Under Test). Normalmente no necesita marcos DI aquí.

Pero. Algunas pruebas de nivel superior aún pueden requerir dependencias no burladas, obviamente. Por ejemplo, desea realizar pruebas en un conjunto grande de datos y no desea crear una fuente de datos falsos especial para mantenerlo en una base de datos real (tal vez también realice algunas pruebas de interfaz de usuario con esos datos). En ese caso, trataría de mantener las cosas lo más simples posible, inicializando las pruebas en los métodos de configuración de clase/configuración de prueba.

Verá, debe tener cuidado aquí.Cada vez que realice una prueba grande y complicada, usted:

1. Cree un código complicado adicional, que requerirá esfuerzos de soporte.
2. Crea una prueba que no tiene una razón clara para fallar. Podría fallar debido a una mala conectividad en ese día. No puedes confiar en su resultado.
3. Crea una prueba que no se puede ejecutar fácil y rápidamente, por ejemplo, al momento del check-in. Menos personas lo ejecutarán, más errores pasarán.

etc ...