Implementando Pruebas Unitarias

 Una de las partes en el proceso de desarrollo que me atrae, es la forma en que se pueden hacer pruebas de los proyectos.

Al inicio las realizamos en forma manual, de hecho, durante mis estudios por la universidad y antes de eso, nos pedían realizar las pruebas de escritorio después de creados los algoritmos, hacer las pruebas después de los diagramas y realizarlas después de codificar.

No hace mucho sugerí que mis compañeros QE comenzaran a realizar pruebas automatizadas y empecé a estudiarlas. No me aceptaron la propuesta, argumentando lo tedioso de realizarlas y mantenerlas.

En los proyectos siguientes, los equipos ya tenían implementadas las pruebas unitarias y de integración para back y front.

En un principio, construirlas resulta una labor cansada y hasta monótona, si es que se realiza en un proceso a mano. Aquí es donde hago uso de patrones de diseño y de arquitectura, herramientas que faciliten esta labor para enfocarme en pruebas más especializadas.

Actualmente estoy implementando genéricos, herencia y como próximo paso utilizaré plantillas.

En este proyecto tengo 15 entidades con sus correspondientes DTOs, Servicios, Repositorios, Controladores, Validadores de negocio y de datos. Y creciendo.

Esto irá para pruebas unitarias, y luego seguiré con las de integración.

Generé una clase base que recibe el servicio y controlador a probar. Así que genero clases derivadas de esa de forma que implementen. De momento solo tengo ahí los llamados a GetAll y GetById. Posteriormente trabajaré con Delete, Post y Put (en ese orden), para luego enfocar en cada clase sus Gets, Posts y Puts específicos, de acuerdo con el comportamiento deseado para la API.

Actualmente generé dos clases base, ya que mis entidades y DTOs están agrupados en dos: con Id Guid y con Id int. Y aunque podría hacerlo más genérico, por el momento es suficiente. Esto me permitió generar nueve pruebas para cada base: dos GET, dos DELETE, dos POST y tres PUT. Y considerando las entidades y DTOs que tengo de inicio, esto me da un total de 117 pruebas unitarias.

Lo importante de definir el tipo de error y los casos, es que permite tener un mayor control de los errores y problemas que la API puede enfrentar.

Al tener bien definido esto, los controladores, servicios y repositorios pueden mejorarse para que puedan gestionar los errores e identificar problemas con antelación. Esto ayuda tanto al desarrollador back-end a mejorar la API, como al desarrollador Front-End para que pueda utilizar correctamente la API, y sepa qué resultados esperar en cada caso.