En la clase anterior nos concentramos principalmente en realizar pruebas de integración: Estamos haciendo tests de componentes que involucran GraphQL, el ORM y la Base de Datos.
No obstante, y cómo muy bien te fijaste, para que nuestra base de datos “responda con algo” tuvimos que imitar su respuesta utilizando librerías como jest-mock y jest-mock-extended.
Si bien el imitar (Mock) nos da mucha flexibilidad y podemos hacer pruebas interesantes donde nos aseguramos que los resolvers llamen algún método en particular con propiedades y argumentos que nos interesen, en la práctica encontraremos que muchos errores de producción, errores reales que experimentan nuestros usuarios, no son detectados en nuestros tests pues estos realmente nunca tocan una base de datos.
Pienso sobre un proyecto en el que recientemente hayas agregado tests y reflexiona sobre lo siguiente:
- ¿Qué riesgos existen cuando la aplicación está en producción? E.j.: ¿Siempre estará disponible la base de datos? ¿La conexión siempre será exitosa? ¿Los datos siempre existirán? ¿Y si no?
- ¿Qué tipo de errores mis tests no podrían detectar con esta estrategia?
- ¿Qué valor agregan mis tests de integración si al final estoy haciendo un mock, realmente tendrá sentido?
Para seguir alimentando nuestra curiosidad sobre testing te dejo estos dos increíbles artículos de Martin Flowers:
- The Practical Test Pyramid
- Testing Strategies in a Microservice Architecture
Y ¿Cómo realizo pruebas End 2 End?
Aunque las lecturas de arriba explican más a detalle sobre esta estrategia de testing, para simplificar las cosas, me gusta verlo como probar todas y cada una de las acciones que un usuario podría hacer con cada uno de los componentes corriendo en el ambiente más real posible.
Las librerías para hacer E2E (End to End) brindan realmente una gran cantidad de métodos para simular con código acciones como: clic, navegar, scroll, llenar formularios, esperar que algo cargue, etc.
Selenium Webdriver ha sido el motor por mucho tiempo que ha permitido hacer esto, la otra gran mayoría de herramientas son una capa encima de Selenium para hacerlo más fácil.
Y actualmente, Cypress, es uno de los software que más fácil y divertido lo pone para hacer pruebas E2E. Además, que integra con una gran cantidad de test suites como Jest y de Continuous Integration systems
Entérate: Qué es End to End testing
Al final, que nuestra aplicación esté disponible para hacer pruebas end to end automatizadas es más un reto de DevOps para lograr crear un ambiente que sea lo más similar posible a la vida real (producción) pero en un ambiente de prueba, hecho para fallar, ser descartable y siempre disponible para los desarrolladores y servidores de testing (CI).
