TESTING de aplicaciones
Integrantes
Matías Chiappe, Agustín Rodriguez
Porque no queremos que todo explote.
¿Qué es el Testing de Aplicaciones?
El testing de aplicaciones es el arte de intentar romper un software antes de que lo haga un usuario furioso.
Se trata de poner a prueba la paciencia de la aplicación, encontrando errores, fallos y cualquier cosa que pueda hacer que la app decida lanzar un error en plena acción.
Consiste en la ejecución de diversas pruebas para identificar errores, defectos o vulnerabilidades.
Testing de Aplicaciones: Porque no queremos que todo explote
Importancia del Testing
Testing de Aplicaciones: Porque no queremos que todo explote
Confiar en que "todo va a salir bien" solo funciona en las películas.
Los tests automatizados sirven para:
-
Verificar el correcto funcionamiento del software en distintos escenarios.
-
Detectar errores tempranamente, reduciendo costos de corrección.
-
Facilitar cambios al proporcionar un "colchón de seguridad".
Problemas que resuelven:
- Fallos en producción por código no validado.
- Incompatibilidades entre aplicaciones.
- Regresiones (errores reintroducidos al hacer cambios).
Tipos de Testing
Existen diferentes tipos de pruebas, dependiendo del objetivo y el nivel de evaluación:
- Tests Unitarios: Pruebas de unidades individuales de código (funciones, clases, métodos) en aislamiento.
Testing de Aplicaciones: Porque no queremos que todo explote
- Tests de Integración: Pruebas que verifican la interacción entre sistemas (por ejemplo APP + API).
- Tests End-to-End (E2E): Pruebas que simulan el comportamiento de un usuario real en la aplicación completa.
Test Unitarios
Su propósito es asegurar que cada unidad haga exactamente lo que se espera sin depender de otros módulos o sistemas.
✅ Ventajas:
- Identifican errores rápidamente.
- Son rápidos de ejecutar.
- Facilitan el refactor sin miedo a romper otras partes del código.
Testing de Aplicaciones: Porque no queremos que todo explote
Test Unitarios
🚀 Ejemplo en JavaScript utilizando Jest:
Testing de Aplicaciones: Porque no queremos que todo explote
Test de Integración
Los test de integración verifican que varios módulos o componentes trabajen correctamente juntos.
Se usan cuando una unidad de código necesita interactuar con bases de datos, APIs, servicios externos o incluso módulos dentro de la misma aplicación.
✅ Ventajas:
- Detectan errores en la comunicación entre módulos.
- Aseguran que las dependencias funcionan correctamente.
Testing de Aplicaciones: Porque no queremos que todo explote
Test de Integración
🚀 Ejemplo en Node.js con Axios (API Express):
Testing de Aplicaciones: Porque no queremos que todo explote
test E2E (End-to-End)
Es una prueba que valida el funcionamiento completo de una aplicación, simulando el recorrido de un usuario real desde el inicio hasta el final de un proceso.
Se utilizan para asegurarse de que todas las partes del sistema, desde la interfaz de usuario hasta la base de datos o servicios externos, interactúan correctamente y logran el resultado esperado.
✅ Ventajas:
- Garantizan que la aplicación funcione correctamente desde la perspectiva del usuario.
- Permite detectar errores que podrían pasar desapercibidos en pruebas más aisladas.
Testing de Aplicaciones: Porque no queremos que todo explote
test E2E (End-to-End)
🚀 A continuación, se presenta un ejemplo utilizando Cypress:
Testing de Aplicaciones: Porque no queremos que todo explote
Comparación de tipos de Tests
Preguntas clave que pueden ayudar a replantear y comparar el uso de distintos tipos de test.
Testing de Aplicaciones: Porque no queremos que todo explote
¿Cuáles de los tipos de test anteriores reconocen?
Comparación de tipos de Tests
Preguntas clave que pueden ayudar a replantear y comparar el uso de distintos tipos de test.
Testing de Aplicaciones: Porque no queremos que todo explote
¿Cuáles de los tipos de test anteriores reconocen?
¿Qué estamos buscamos validar?
- ¿Necesitamos verificar la lógica interna de una función específica? (Unitario)
- ¿Queremos asegurar que dos o más módulos interactúan correctamente? (Integración)
- ¿Buscamos simular el comportamiento del usuario en la aplicación completa? (E2E)
Comparación de tipos de Tests
Preguntas clave que pueden ayudar a replantear y comparar el uso de distintos tipos de test.
Testing de Aplicaciones: Porque no queremos que todo explote
¿Cuáles de los tipos de test anteriores reconocen?
¿Qué estamos buscamos validar?
¿Qué tan frecuente cambiará el código testeado?
- ¿Se trata de lógica estable que rara vez cambia? (Unitarios)
- ¿Es una API o servicio externo que podría actualizarse y romper compatibilidad? (Integración)
- ¿Es una interfaz de usuario que puede cambiar con frecuencia? ( E2E)
Comparación de tipos de Tests
Preguntas clave que pueden ayudar a replantear y comparar el uso de distintos tipos de test.
Testing de Aplicaciones: Porque no queremos que todo explote
¿Cuáles de los tipos de test anteriores reconocen?
¿Qué estamos buscamos validar?
¿Qué tan frecuente cambiará el código testeado?
¿Qué tan costoso es mantener los tests?
- ¿Podemos permitirnos escribir muchas pruebas rápidas y fáciles de actualizar?
- ¿Podemos invertir en pruebas más complejas para validar la integración de módulos?
- ¿El esfuerzo de mantenimiento de pruebas E2E justifica su valor en términos de prevención de errores?
Comparación de tipos de Tests
Preguntas clave que pueden ayudar a replantear y comparar el uso de distintos tipos de test.
Testing de Aplicaciones: Porque no queremos que todo explote
¿Cuáles de los tipos de test anteriores reconocen?
¿Qué estamos buscamos validar?
¿Qué tan frecuente cambiará el código testeado?
¿Qué tan costoso es mantener los tests?
¿Dónde queremos detectar los errores?
- Preferimos atraparlos en la etapa de desarrollo antes de que lleguen a otras partes del código? (Unitarios)
- ¿Necesitamos identificarlos cuando un servicio no responde como se espera? (Integración)
- ¿Queremos asegurarnos de que un usuario real no se encuentre con fallos en producción? (E2E)
¿Cuáles utilizar y cuáles no?
La elección entre distintos tipos de tests depende de varios factores, como el tipo de proyecto, la complejidad del software, los recursos disponibles y la cultura de pruebas dentro del equipo.
Testing de Aplicaciones: Porque no queremos que todo explote
¿Cuáles utilizar y cuáles no?
Según la opinión de algunos expertos:
Equipos pequeños:
✅ Unitarios y algunos de integración (para asegurar calidad sin sobrecarga).
❌ Tests E2E pesados, ya que son costosos de mantener.
Equipos medianos con desarrollo ágil:
✅ Unitarios, integración y tests exploratorios.
⚠️ Tests E2E limitados solo en flujos críticos.
Grandes empresas / Software crítico:
✅ Combinación de unitarios, integración y E2E bien estructurados.
✅ Pruebas de rendimiento, seguridad y exploratorias.
Testing de Aplicaciones: Porque no queremos que todo explote
¿Cuáles utilizar y cuáles no?
La estrategia de testing debe adaptarse al contexto del equipo y del software.
En general, la recomendación de expertos es:
- Test unitarios para lógica pura.
- Test de integración para verificar interacciones entre módulos.
- Test E2E solo para flujos críticos (ej. proceso de pago, login).
- No depender solo de tests E2E, ya que son costosos de mantener y lentos.
Estrategia recomendada:
✅ 70% test unitarios
✅ 20% test de integración
✅ 10% test UI/E2E (solo lo esencial)
Testing de Aplicaciones: Porque no queremos que todo explote
¿Cuáles utilizar y cuáles no?
Uno de los enfoques más populares es la pirámide de pruebas propuesta por Mike Cohn en su libro Succeeding with Agile:
Este modelo sugiere que la estrategia de pruebas debe basarse en tres niveles, priorizando los tests más rápidos y menos costosos en la base:
Testing de Aplicaciones: Porque no queremos que todo explote
- Base: Tests unitarios → Deben ser la mayoría, ya que son rápidos, confiables y fáciles de mantener.
- Medio: Tests de integración → Validan interacciones entre módulos y deben estar bien balanceados.
- Cima: Tests E2E → Deben ser los menos frecuentes, ya que son costosos, frágiles y tardan en ejecutarse.
¿Debería hacer test de UI?
Los test de UI (end-to-end o E2E) verifican el comportamiento completo de la aplicación:
❌ Desventajas:
- Son lentos y consumen más recursos.
- Son frágiles: cambios menores en la UI pueden romper muchas pruebas.
- Más difíciles de mantener.
Si tu aplicación tiene una arquitectura bien desacoplada, los test de integración pueden cubrir la mayor parte de los casos sin necesidad de pruebas UI excesivas.
Testing de Aplicaciones: Porque no queremos que todo explote
Ejemplo Práctico y Problema
Imagina el siguiente escenario en el que se implementa un test E2E para verificar el proceso de inicio de sesión:
Testing de Aplicaciones: Porque no queremos que todo explote
Ejemplo Práctico y Problema
El test valida que, después de un inicio de sesión exitoso, se muestre el mensaje "Bienvenido, usuario".
Supongamos que se decide actualizar el mensaje a "¡Hola, Juan! Bienvenido de nuevo.".
Aunque el proceso de autenticación sigue funcionando correctamente, el test fallará porque el mensaje esperado ya no coincide exactamente con el texto mostrado.
Testing de Aplicaciones: Porque no queremos que todo explote
El valor del test se limita a avisar sobre cambios en el diseño en lugar de validar que el proceso de login funcione correctamente.
Trabajo en equipo
El uso de tests E2E no reemplaza la necesidad de que miembros del equipo revisen la aplicación como usuarios. Ambos enfoques son complementarios.
Testing de Aplicaciones: Porque no queremos que todo explote
La evaluación humana es crucial para detectar aspectos de usabilidad, experiencia de usuario y detalles subjetivos que las pruebas automatizadas no pueden captar.
¿Qué tipo de errores puede detectar la revisión humana?
¿Podemos encontrar una nueva forma de testear en equipo?
Trabajo en equipo
Para complementar y mejorar la capa de testing es recomendable combinar la inspección humana con diversas herramientas y metodologías de automatización.
Testing de Aplicaciones: Porque no queremos que todo explote
1. Integración de Tests Automatizados en el Flujo de PR
Configura flujos de trabajo (por ejemplo, con GitHub Actions) que se disparen automáticamente al crear o actualizar una PR.
2. Uso de Plantillas y Checklists para PRs
Establece plantillas de PR que incluyan secciones específicas donde se requiera indicar qué pruebas se han agregado o actualizado.
3. Revisión y Retroalimentación Enfocada en Tests
Durante la revisión de la PR, los revisores deben prestar especial atención a la parte de testing.
4. Cultura de Test Driven Development (TDD) y Revisiones Colaborativas
Promueve TDD para que la creación de nuevas funcionalidades vaya siempre acompañada de tests.
¡GRACIAS!
Gracias.