¿Debo usar AutoMapper en mis pruebas unitarias?

Question

Estoy escribiendo pruebas de unidad para los métodos de controlador ASP.NET MVC.

Esos controladores tienen una dependencia en IMapper - una interfaz que he creado para abstraer AutoMapper, pasado a través de la inyección del constructor usando Castle Windsor.

Los métodos de acción usan IMapper para asignar objetos de dominio a objetos ViewModel y viceversa, con el objetivo de mantener las cosas SECAS y mantener los métodos de acción concisos.

En mis pruebas de unidad, debo

1. Configurar AutoMapper con las fijaciones correctas (que están construidos con perfiles AutoMapper, por lo comprobable y reutilizables entre proyectos web y los exámenes de unidad) y pasar esa sesión como adecuada implementación de AutoMapper de IMapper.

2. Pase en objetos simulados (estoy usando Moq) para la instancia IMapper, dependiendo de la prueba (esto significaría duplicar algún trabajo en el código de configuración de prueba para asegurarse de que los objetos devueltos del mapeador simulado se relacionan con el objetos que el mapeador falso simula hacer un mapa).

3. Configurar manualmente AutoMapper con solo las asignaciones que creo que necesitaré para cada prueba (mucho trabajo y significa que no estoy probando las asignaciones que realmente estarán en uso).

¿Cuál es la opinión sobre el uso del código de infraestructura en las pruebas unitarias? ¿En qué punto se convierte en una prueba de integración (es decir, prueba la integración de AutoMapper y mis controladores)?

Parece que 2 es la vista purista, aunque creo que necesito aprender más sobre Moq y cómo lograr que devuelva valores relacionados con los valores reales pasados ​​a los métodos que se burlan.

Answer 1

Podría estar de acuerdo con el n. ° 2. Usted sabe que el automapper funciona, usted sabe que su inyección funciona (¿se hicieron pruebas para eso? :-)) Me centraría más en detalles, cosas que no son solo SomeClass.Property = AnotherClass.Property - ESOS casos especiales deberían probarse no funciones básicas de copia No pruebes cosas del framework.

En cuanto a más código de prueba, creo que está completamente bien. Las pruebas se deben configurar dentro de las pruebas dadas (también dentro de lo razonable) solo para esa unidad determinada.

En cuanto a Moq, la sintaxis es fácil, no lo piense demasiado. var obj = new Mock(); luego configure sus propiedades como obj.Setup (x => x.Property) .returns ("hello") a menos que tenga un problema más específico. Moq también ha configurado todas las propiedades en él, por lo que es posible que ni siquiera necesite automapper

-edit- lo encontró, es obj.SetupAllProperties();

Answer 2

estoy a favor de la # 2 como jeriley

Agregando a la Moq, si usted necesita devolver un objeto basado en valores pasados ​​a él se puede escribir la configuración de este modo:

mockObject.Setup(x => x.MapObject(It.IsAny()) 
      .Returns((ProductDto productDto) => 
      { 
       var product = new Product() 
       { 
        Id = productDto.Id, 
        Name = productDto.Name 
       }; 

       return product 
      });

Poco sucio pero práctico.