Estoy probando un servicio de mi aplicación que depende de otros servicios en tiempo de ejecución. Al probar, la inyección de dependencia parece no funcionar. ¿La inyección de dependencia funciona en los artefactos de Grails cuando se ejecutan pruebas de integración?Inyección de dependencia en las pruebas de integración de Grails
Respuesta
Sí, cuando se ejecutan pruebas (es decir, aquellas en el directorio de integración), la aplicación se inicia y todos los beans se crean y se inyectan como si la aplicación se estuviera ejecutando realmente. La única diferencia entre la aplicación de prueba y la aplicación en ejecución debe ser el entorno de configuración.
Por supuesto, si instancia una clase que requiera inyección utilizando el "nuevo" operador en su prueba, no obtendrá los beneficios de DI. En su lugar, crear una propiedad en el caso de test para el bean de sus pruebas y se le inyectará:
class MyServiceTests extends GrailsUnitTestCase {
MyService service
void testInjection() {
assertNotNull service
}
}
Para aquellos de ustedes usando Grails 1.3.7, me he dado cuenta que no puede utilizar el nombre de clase para que la Inyección de Dependencia funcione. En su lugar, declare el servicio como:
def myService
y luego ocurre la magia DI. Con el código anterior en 1.3.7 la aserción no nulo fallaría.
1.3.7 y superior. Este es un problema en 2.4.x también. Además, para las pruebas de integración del controlador debe crear una instancia del controlador: 'def fooController = new FooController()' - entonces las dependencias estarán cableadas correctamente. –
- 1. Pruebas de integración NUnit e inyección de dependencia
- 2. Grails pruebas de integración con servicios múltiples
- 3. Iniciando Grails durante las pruebas de integración
- 4. Grails pruebas y transacciones de integración
- 5. Inyección de dependencias en las pruebas
- 6. Pruebas de integración y unidad en el gran proyecto Grails
- 7. alternativas de inyección de dependencia
- 8. Además de las pruebas, ¿cómo es la Inyección de Dependencia mejor que las clases/métodos estáticos?
- 9. ¿Cómo automatizar las pruebas de integración?
- 10. Inyección de dependencia en MVC
- 11. La inyección de dependencia para NServiceBus pruebas unitarias manejador
- 12. Inyección de Dependencia wcf
- 13. Burlarse de las pruebas de integración
- 14. Maven: pruebas de integración por separado de las pruebas unitarias
- 15. ¿Separa las pruebas unitarias de sus pruebas de integración?
- 16. ¿Cómo organizar las pruebas de integración?
- 17. ¿Cómo hacer las pruebas de integración?
- 18. Inyección de dependencia sin marco
- 19. C++ y la inyección de dependencias en las pruebas unitarias
- 20. Inyección de Dependencia con PowerShell
- 21. Inyección de dependencia con Jersey
- 22. Pruebas de integración vs. Pruebas unitarias
- 23. configuración simulada en las pruebas Grails
- 24. Pruebas de integración de rieles
- 25. Sistema de archivos falso en las pruebas de integración
- 26. Burlarse sin IoC o Inyección de Dependencia
- 27. @ExpectedException en las pruebas de la unidad de grails
- 28. Inyectando el Inyector de Dependencia usando la Inyección de Dependencia
- 29. ¿Pruebas unitarias o pruebas de integración?
- 30. ¿Cómo se separan las pruebas unitarias de las pruebas de integración en Visual Studio?
Gracias. Estoy probando un servicio que depende de otros servicios y lo estaba creando y, debido a esto, no obtuve los beneficios de DI. – Lucas
Sólo una nota al margen. Las pruebas de integración no deberían extender GrailsUnitTestCase, dependiendo de la versión, esto puede causar serios problemas con su ConfigurationHolder.config como nulo. Yes grails create-integration-test en muchas versiones crea una prueba que extiende GrailsUnitTestCase, pero este es un error que se ha solucionado recientemente. –
¿Por qué la respuesta dice "por supuesto, si instancia una clase que requiere inyección", no obtendrá DI? ¿Por qué es ese el caso en general? No fue obvio para mí, aunque penosamente lo descubrí. –