¡Hola!
El otro día haciendo la kata Gilded Rose (una de las más interesantes que he hecho), me encontré con una curiosa herramienta llamada ApprovalTests. Esta librería, que tiene ya unos cuantos años, nos ayuda a escribir test de aprobación. Este tipo de test los utilizaremos típicamente cuando nuestros Asserts sean muy costosos o queramos refactorizar código (como en la kata). Antes que nada, os recomiendo dejar de leer esta entrada y leer estas otras del blog Koalite que son mucho más interesantes (y con mejor criterio), y si no conoces el blog, ya puedes añadirlo a tus marcadores.
Como comentaba, los test de aprobación los vamos a utilizar cuando es demasiado costoso (por complejidad o por tiempo) definir los Asserts de nuestros test o es complicado automatizar la decisión de que lo que estamos testeando es correcto. Por ejemplo, si estamos generando un reporte de una factura, puede que nos sea suficiente una validación a ojo de buen cubero en la que veamos el reporte y digamos, esto nos vale; aquí podrían encajar los test de aprobación porque nos va a resultar muy sencillo hacer el test, y nos va a dar la seguridad de que si hacemos algún cambio en código que modifique sin querer el reporte, tengamos la seguridad de que el test va a fallar. Otro caso donde nos puede interesar es cuando estamos haciendo test de caracterización en legacy code, en los que simplemente nos interesa tener nuestra red de seguridad que nos avise si estamos rompiendo algo del código cuando tratamos de añadir nuestra nueva funcionalidad (justamente este es el caso de la kata Gilded Rose). Con la librería Approval Test, y seguramente con alguna herramienta de cobertura de test, conseguiremos hacer test bastante rápido que nos ayuden a desarrollar esta nueva funcionalidad asegurándonos de no estropeamos nada, eso sí, no todo es Jauja, muchas veces esos test no nos van a quedar muy bonitos ni expresivos, pero nos pueden ayudar mucho como punto de partida.
Ejemplo rápido
Es posible que todavía no tengas mucha idea de cómo funciona este tipo de test, por lo que voy a enseñar un ejemplo rápido y, a partir del ejemplo, iremos profundizando un poco en la herramienta. Vamos a imaginarnos que estamos generando un ticket en texto plano y queremos validar que el formato es correcto. Lo primero es instalar el paquete ApprovalTests en nuestro proyecto de test; lo podemos hacer a través de NuGet. Y generamos el siguiente test:
1 2 3 4 5 6 7 8 9 10 | [UseReporter(typeof(DiffReporter))] public class ApprovalBasicTest { [Fact] public void ValidateTicketFormat_Test() { string ticket = GivenATicket(); Approvals.Verify(ticket); } } |
Lo primero en lo que nos damos cuenta es que no hay el típico assert donde comprobamos dos valores. Realmente sí lo hay, lo que pasa que el valor expected del assert no se codifica, sino que lo determinamos nosotros cuando veamos el resultado. Otra cosa que vemos es que en la línea 1 estamos definiendo un UseReporter, en concreto DiffReporter. Esto lo veremos más adelante, pero quiere decir el tipo de reporte que se generará y será lo que tengamos que validar. Llegados a este punto, vamos a ejecutar el test a ver qué pasa:
El test ha fallado y se ha abierto la herramienta para comparar código de Visual Studio. ¿Qué nos quiere decir esto? En la parte izquierda nos está mostrando el ticket que se ha generado con el test, y en la parte de la derecha el ticket que nosotros hemos aprobado como válido… pero espera, nosotros no hemos validado todavía ningún ticket, ¡claro, es la primera vez que pasamos el test! Aquí es donde nosotros tenemos que aprobar el test y decidir si este resultado es el correcto que, en nuestro caso, sí lo es. ¿Cómo lo hacemos? Volvemos de nuevo a la imagen anterior y vamos a echar un vistazo al nombre de los archivos que se han generado:
Tenemos dos archivos, uno approved.txt y el otro received.txt. Lo que se va a hacer es, cada vez que se pase el test se va a generar un archivo received con el resultado del test y se va a comparar con el valor del archivo approved. La primera vez que pasamos el test ese archivo no existe, por lo que se va a crear vacío. Ahora que sabemos que el resultado es correcto vamos a sustituir nuestro archivo …approved.txt por el archivo …received.txt (veremos más adelante formas de hacer esto más rápido), para indicar que nuestro archivo aprobado es el que veíamos a la izquierda de la imagen. Si volvemos a pasar el test, ahora ya está en verde:
Si echamos un vistazo a los archivos, el archivo …received.txt no se ha vuelto a generar, porque realmente no es necesario ya que se ha comprobado que el resultado es correcto, por lo que no necesitamos compararlo ni validarlo. Si ahora modifico el formato de mi ticket, vemos cómo falla de nuevo el test:
Ahora es donde nosotros entramos de nuevo en juego y tenemos que decidir si este nuevo formato de ticket es o no correcto.
Conclusiones
Después de este rápido (muy rápido) vistazo a la herramienta, podemos empezar a hacernos un idea de dónde podría encajar a la hora de crear nuestros tests. Voy a intentar hacer una serie de post intentando profundizar un poco en cómo utilizarla, cómo configurarla y qué puntos débiles creo que tiene.
¡Un saludo!
2 thoughts on “Test de aprobación con ApprovalTests. Conceptos básicos”