Cómo evitar romper tus sistemas legacy, validar la UI o testear tu API |

Ricardo Borillo nos trae unos ejemplos prácticos para aprender más sobre "Approval Testing". Quizás os suenen los términos "Snapshot Testing", "Golgen Master Testing", o "Characterisation Testing". Este tipo de técnicas para validar que nuestro software se comporta como esperamos son especialmente útiles en entornos por ejemplo donde tenemos que lidiar con sistemas heredados (legacy) que no tienen tests, queremos validar a nivel de UI, o incluso nuestras APIs HTTP.
En este directo hablaremos sobre los beneficios y contraprestaciones de este tipo de técnicas 😊
Approval Testing
⚠️ No todos los tipos de test sirven para todas las situaciones. Cada tipo de test es efectivo en un contexto.
¿Que son y cómo funcionan?
🧠 Approval Testing = Snapshot Testing | Golden Master Testing | Characterisation Testing.
Proceso:
- Creamos un test asociado a un comportamiento concreto.
- Escribimos el código necesario para que el test pueda pasar.
- Ejecutamos el test y se registra la SNAPSHOT.
- Aprovamos la SNAPSHOT si el comportamiento es el correcto.
- Solo aprovaremos una nueva SNAPSHOT si el comportamiento cambia.
🏎️ Evolución de los tests parametrizados.
⚙️ Muy útiles para entornos Legacy, UI o API testing (SNAPSHOT = DOM fragment | API response | class instances).
🤯 Es posible hacer TDD con este enfoque.
Puntos fuertes
🥳 Mejor cuando la superficie del test es grande o asserts complejos.
🧡 Mejor en funciones puras (respuestas idempotentes).
🎱 Las SNAPSHOTS se pueden grabar de producción cuando es complejo generar escenarios de test realistas.
Puntos débiles
😞 Crítica del gurú por tener que entender y aprobar los cambios. Example mapping.
😢 Es complicado identificar los valores correctos cuando aumentan las combinaciones de valores.
Siguientes pasos
🔥 Mutation testing para verificar nuestras SNAPSHOTS.
💡 Property-based testing: Los tests no comprueban el output, sino propiedades de la solución = Mayor mantenibilidad
﹤🍍﹥ Links relacionados
Enlaces comentados en el vídeo
├ 📝 Oferta empleo Declarando: bit.ly/oferta-declarando
├ 🎥 Vídeo relacionado de Mutant testing: ruclips.net/user/liveMiWRwGUnCjk
├ ✅ Encuesta interés en curso Approval Testing: forms.gle/eTd3rRAe1ng868t87
├ 👩‍👧 Emily Bache: / emilybache
├ 🎥 Emily Bache Tech Coach: / @emilybache-tech-coach
├ 🎥 Introducing the Gilded Rose kata and writing test cases using Approval Tests: • Part 1/3 - Introducing...
├ 🎥 Refactoring Intro y Live Coding Kata Gilded Rose: • Refactoring Intro y Li...
├ 📄 Approval Testing: Agile Testing that Scales: www.methodsandtools.com/archi...
Librerías comentadas:
├ ⌨️ jest-snapshot: www.npmjs.com/package/jest-sn...
├ ⌨️ jest-extended-snapshot: www.npmjs.com/package/jest-ex...
├ ⌨️ approvals: github.com/approvals/Approval...
Redes sociales Codely
├ 🎥 Suscríbete: ruclips.net/user/CodelyTV?sub_co...
├ 🐦 Twitter CodelyTV: / codelytv
├ 👋 Twitter Ricardo Borillo: / borillo
├ 🫧 Twitter Javi: / javiercane
├ 📸 Instagram: / codelytv
├ ℹ️ LinkedIn: / codelytv
├ 🟦 Facebook: / codelytv
└ 📕 Catálogo cursos: bit.ly/cursos-codely

[@aikenfdez6588]

Casi al final del video, Ricardo comenta que con un cliente tuvieron que "grabar" el input de de producción como método terminal de conseguir los casos de uso cuando el cliente no te los da. Estuvo a punto de comentar la herramienta que usaron, pero creo que finalmente no la dijo, podrían dar algo de información de alguna herramienta de este tipo. Si fuera para php genial, o sino como se llaman este tipo de herramientas.