La solución añade un proyecto "Test" ubicado en una carpeta de solución "Tests".
Los tests se realizan por cada acción de controlador, método de servicio y método de repositorio. La nomenclatura utilizada fue la siguiente:
[NombreMetodo+arragingFakeEntidad] _ [objetoqueesperarecibir] _ [tipoobjetoqueesperadevolver] _
[Controller/Service/Repository+Unit/Integration+Test].
Utilizan el patrón AAA y siguen
las especificaciones explicadas
aquí.
No son únicos puesto que se crean algunos que esperan
una excepción cuando la
forzamos por un error de lógica.
Son de tipo unitarios y de integración entendiendo estos últimos como un Test donde cargamos una entidad fake no sobre el EF sino guardando además en Base de Datos.
El nombre de la entidad ficticia principal a partir de la cual "cuelgan" el resto es el propio nombre del Test. Esto será importante para su posterior borrado en los de integración.
Para ubicarlos de una forma estructurada dentro del proyecto se crearon las carpetas "UnitTests" e "IntegrationTests", y en cada una de ellas las subcarpetas "Azure", "Controllers", "Services" y "Repositories"
El "AppConfig" de dicho proyecto de Tests contiene las 3 diferentes cadenas de conexión para en Debug (Solution Configuration) poder "atacar" a la BBDD apropiada. Además se añade SlowCheetah - XML Transforms Preview for 2015 para transformarlo en Debug, Development y UAT para que tome la cadena de conexión adecuada según el Solution Configuration al compilar. Esto es muy óptimo cuando se pasan los Tests antes del despliegue en DEV_Web, DEV y UAT correspondiente.
Para los test unitarios sobre los controladores se utiliza el paquete de Nuget Moq. Los Moqs son generados en una clase independiente "MocksForControllers" con métodos estáticos donde generar las distintas entidades. En general se sigue el siguiente modelo.
Los Test de integración generan entidades ficticias agrupadas en una clase "Mother" para una mejor organización.
La comprobación de la previsión en los Tests de integración (3ª A) se realiza con queries directas sobre la BBDD.
Cuando todos los TestMethods de TestClass generan el mismo Fake se realiza en el TestInitialize para evitar código duplicado.
Para borrar los registros ficticios en Base de datos aplicamos 2 medidas: