Unittesting IoC registro?

Question

¿Debe probar el código que registra los componentes en su contenedor IoC?

Si es así, ¿cómo?

Answer 1

Debido a que sus componentes pueden tener sus propias dependencias o realizar alguna inicialización Me cubrir este escenario con los UT.

Algo así como

iocContainer.Register(typeof(MyService1)); 
service = iocContainer.Get(typeof(MyService)); 
Debug.AssertNotNull(service); 

Answer 2

En primavera se puede tener una unidad de prueba que simplemente carga el contexto de aplicación sin afirmar nada. En realidad, es una prueba bastante útil junto con la compilación automática, ya que la primavera se queja de muchos problemas al cargar todo el contexto.

Answer 3

estoy usando Windsor en un proyecto ASP.NET MVC donde he escrito una simple prueba para verificar que todos los controladores se pueden crear instancias (es decir, sus dependencias se pueden resolver).

Tengo una prueba para cada configuración del sitio web (por ejemplo, "desarrollo", "prueba", "algúnSitio de producción", etc.) donde creo mi contenedor Windsor con esa configuración particular y recorro todas las implementaciones no abstractas de IController, comprobando que puedo resolver una instancia de cada uno.

Desde la fábrica de controlador es el único punto de entrada a la aplicación que se traducirá en una container.Resolve (...), estoy 100% seguro de que todas las configuraciones son válidas.

En general, he encontrado que escribir pruebas que funcionan como afirmaciones sobre la totalidad del sistema son extremadamente útil y valiosa.

E.g. También estoy afirmando que todas las acciones del controlador son virtuales, lo cual es un requisito, porque estoy usando la gestión automática de transacciones de Castle para rodear las acciones del controlador con las transacciones.

Answer 4

@aku, @krosenvold y @mookid hacer un argumento convincente para las pruebas de que la configuración de las dependencias es correcta.
No creo que esto sea unidad probando sin embargo.
¿Qué estás probando? No está tratando de probar el contenedor por sí mismo (presumiblemente, ese no es el código que escribió o está manteniendo).
Lo que está intentando probar es que se pueden crear todas las dependencias de un tipo particular y que el tipo se puede resolver. Esto parece una prueba de sistema bastante útil o una prueba de integración para tener en su entorno de integración continua.
Así que una vez que tenga los binarios que pasan la prueba unitaria, puede crear el contenedor y ejecutar la configuración del contenedor en una máquina que refleje su entorno de producción y probar que cada uno de los tipos que el contenedor debería poder resolver puede ser creado y todas sus dependencias pueden ser instanciadas.
Sería bueno ejecutar esto en una máquina virtual nueva a la que haya aplicado su último instalador.

Answer 5

Puede ser útil debido a que algunos marcos de inyección de dependencia (como unidad) tienen extrañas reglas para elegir qué constructor para llamar. Definitivamente recomendaría pruebas unitarias para asegurarme de que el registro y la creación de su tipo se realicen con éxito.

Answer 6

De alguna manera, me parece incorrecto tener el contenedor de IoC ejecutándose en mis proyectos de prueba. También noté que la mayoría de los errores provocados por las dependencias que no se resuelven son causados ​​por el orden en que se resuelven las dependencias, esto es muy difícil de evaluar correctamente y no es algo que quisiera hacer como una prueba unitaria.

Normalmente uso declaraciones Debug.Asert en las rutinas de inicialización de mis clases. Esto me da un sistema de alerta temprana para los errores relacionados con la IoC y también ayuda a especificar mejor las dependencias en mi código.

Answer 7

Lo que hago con el contenedor IoC Guice, es que primero produzco las clases para algunas funciones usando TDD sin Guice (estas son pruebas unitarias). Luego creo una prueba de integración para esa función con Guice. En ese momento, la configuración de IoC (módulo de Guice) está incompleta, por lo que la prueba de integración fallará. Utilizando TDD, agrego la configuración de IoC paso a paso hasta que pasa la prueba de integración. No añadiré ninguna anotación @Inject, línea de configuración o declaración de ámbito, a menos que sea necesario pasar una prueba. Como resultado, tendré pruebas de integración (o aceptación) asegurándome de que la configuración de IoC sea correcta y completa.

Este mismo método debería funcionar con cualquier contenedor IoC u otro sistema, cuya configuración es tan compleja que puede romperse: no escriba ninguna configuración a menos que sea necesario pasar una prueba.

Answer 8

respuesta a esta pregunta específicamente para Castle Windsor:

Castle Windsor: How to test that all registered components are resolvable?