¿Cómo se usa la inyección de resorte para probar la unidad de un controlador?

Question

Quiero probar mi controlador mvc de primavera.

El controlador dispone de un servicio:

@Autowired 
UserService userService 

Y mi servicio de usuario depende de (autowired) mi UserDao y algunos otros servicios como MongoDB etc.

Ahora quiero la lógica de negocio a ensayar en mi UserService, pero por supuesto quiero simular las respuestas de mi UserDao y Mongodb, etc.

¿Cómo configuro mi unidad de prueba correctamente?

¿Puedo volver a utilizar el archivo xml del contenedor de primavera que tiene todos mis frijoles, etc. o puedo crear uno nuevo? (supongo que tengo que obtener el contenedor de primavera involucrado aquí)

Buscando alguna orientación sobre esto, cualquier tutorial sería muy apreciado.

actualización

Lo que me parece extraño es que para mi controlador de muelle (que no implementa a partir del regulador) pude acceder a mi varialbe privada para configurar manualmente mi servicio, es decir:

@Controller 
public class UserController { 

    @Autowired 
    UserService userService; 
} 

Y en mi unidad de prueba que podía hacer:

UserController controller = new UserController(); 
controller.userService = .... 

Pero para mi UserService, que tiene UserDao autowired, no puedo acceder la propiedad UserDAO:

UserService userService = new UserServiceImpl(); 
userService.userDao = .... // not available 

Tiene sentido, ya que es privado, pero ¿Cómo es trabajar para el controlador?

Answer 1

Marco de primavera tiene características muy interesantes para la prueba. Puede echar un vistazo al Spring reference guide. Puede proporcionar DI incluso en su clase de prueba JUnit.

@RunWith(SpringJUnit4ClassRunner.class) 
// ApplicationContext will be loaded from "/applicationContext.xml" and "/applicationContext-test.xml" 
// in the root of the classpath 
@ContextConfiguration(locations={"/applicationContext.xml", "/applicationContext-test.xml"}) 
public class MyTest { 
    // class body... 
} 

En pocas palabras, puede utilizar su propio applicationContext.xml o incluso definir uno nuevo sólo para las pruebas. Yo personalmente uso uno diferente ya que defino otro dataSource dedicado para fines de prueba.

Answer 2

Lo que me parece extraño es que para mi controlador de muelle (que no implementa a partir del regulador) pude acceder a mi varialbe privada para configurar manualmente mi servicio, es decir:

Esto es fácil : la variable no es privada

Tiene la visibilidad predeterminada ("paquete privado"). Esto significa que puede acceder a ellos desde todas las clases del mismo paquete.

Si tiene una estructura común, entonces el controlador y el caso de prueba del controlador están en el mismo paquete. Por lo tanto, puede modificar los campos del controlador ("paquete privado"). Pero el caso de prueba del controlador y el servicio no están en el mismo paquete, por lo que no puede acceder a los campos de servicio ("paquete privado").

Answer 3

¿Puedo volver a utilizar el archivo xml del contenedor de resorte que tiene todos mis frijoles etc. o puedo crear uno nuevo? (Supongo que tengo que obtener el contenedor de primavera involucrado aquí)

Recomendaría no crear un nuevo archivo xml. Terminarías duplicando muchas cosas y sería difícil de mantener. Habría una proliferación de archivos de configuración. Pones la configuración requerida para las pruebas en un xml diferente y eso ni siquiera debería implementarse en tu caja de producción. En cuanto a usar la configuración para sus beans, puede emplear el mecanismo sugerido por @Trein.

Para probar contrller de muelles en general, también puede encontrar este SO Thread útil.

Espero que ayude.