Pruebas Unitarias con NUnit para Inyección por Dependencia

Una tarea que nos suele generar algunos dolores de cabeza con las pruebas unitarias es cuando tenemos implementado patrones como el Repository Pattern en nuestro código o el acceso a los servicios se resuelve vía inyección por dependencia (DI Pattern).

En el siguiente artículo daré algunos tips y framework’s que me han servido mucho para ir resolviendo y acelerando la construcción de piezas con foco en TDD sin tener que lidiar demasiado con la configuración del proyecto de pruebas.

Sin entrar en mayores detalles entorno al proyecto que se está desarrollando la estructura que suelo utilizar para subdividir la arquitectura del mismo es la construcción en capas:

Gecap.Data

Contiene toda la infraestructura de acceso a datos a través de Entity Framework.

Gecap.Business

Contiene toda la lógica de negocios del proyecto y la estructura base de los repositorios de acceso a la base de datos. En esta capa se implementan 2 patrones que considero útiles: Repository Pattern y Unit Of Work. A través del repositorio base puedo implementar la lógica genérica de un CRUD e ir creciendo en la medida en que las necesidades del proyecto así lo manifiesten. En el caso de Unit Of Work me provee un acceso unificado o una sola unidad de trabajo a todos los repositorios de acceso a la base de datos (a través de Entity Framework), haciendo más sencillo el proceso de testing.

En esta capa además se proveen los servicios que son los que se exponen a los clientes. Cada servicio puede tener acceso a uno o más repositorios dependiendo de la lógica de negocios que intente satisfacer, el acceso a los repositorios es a través de Unit Of Work.

En el caso del servicio anterior se retorna una lista de modelos que son copias casi exactas de las entidades que provee Entity Framework.

Gecap.WebApp

Corresponde a la aplicación web que mostrará a los usuarios las funcionalidades a través de diferentes interfaces de usuario. En la app web los servicios se inyectan a través del framework Unity:

Testing

Descripción detallada de las librerías utilizadas:

Moq: El término mock, técnicamente en castellano significa burlarse, y en este contexto no tiene sentido, pero uno de sus sinónimos es “mimic” el cual significa mímica, que es lo mismo que imitar. Excelente explicación de Netmentor en su blog.

NUnit: NUnit es un framework open source de Pruebas de unidad para Microsoft .NET y Mono. Sirve al mismo propósito que JUnit realiza en el mundo Java, y es uno de muchos en la familia xUnit.

Unity: framework que provee la infraestructura necesaria para implementar dos patrones de diseño: IoC (Inversion Of Control) y DI (Dependency Injection). Ejemplo

Estructura de la prueba unitaria

Configurando la prueba unitaria

Lo primero que debemos hacer es declarar a nivel de clase la variable que se usará para guardar el “contenedor” de Unity y el “Imitador” de las evaluaciones, que corresponde al Mock de la interfaz del servicio.

El método init corresponde al “configurador” de la prueba unitaria, ahí se levanta el contenedor, el Mock y se registra dicho Mock en el contenedor.

Construyendo la prueba unitaria

Inicialmente se resuelve la clase EvaluacionService que anteriormente se había registrado en el SetUp, luego obtenemos desde el servicio las evaluaciones por establecimiento según la regla de negocio que queramos probar. Finalmente se evalúa si el objeto es distinto de NULL y si la lista contiene al menos una evaluación.

Ejecutando y depurando

Ponemos un punto de interrupción en el código del test y ejecutamos el debug:

Verificamos en el visor de variables:

Tenemos ya los mismos 3 resultados que obtuvimos desde la consulta a la BD

Espero que haya sido de utilidad el artículo…

Nos vemos en la próxima entrega