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.

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).

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.

• 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.

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.

🚀 Ejemplo en JavaScript utilizando Jest:

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.

🚀 Ejemplo en Node.js con Axios (API Express):

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.

🚀 A continuación, se presenta un ejemplo utilizando Cypress:

Preguntas clave que pueden ayudar a replantear y comparar el uso de distintos tipos de test.

¿Cuáles de los tipos de test anteriores reconocen?

Preguntas clave que pueden ayudar a replantear y comparar el uso de distintos tipos de test.

¿Cuáles de los tipos de test anteriores reconocen?

¿Qué estamos buscamos validar?

Preguntas clave que pueden ayudar a replantear y comparar el uso de distintos tipos de test.

¿Cuáles de los tipos de test anteriores reconocen?

¿Qué estamos buscamos validar?

¿Qué tan frecuente cambiará el código testeado?

Preguntas clave que pueden ayudar a replantear y comparar el uso de distintos tipos de test.

¿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?

Preguntas clave que pueden ayudar a replantear y comparar el uso de distintos tipos de test.

¿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?

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.

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.

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)

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:

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.

Imagina el siguiente escenario en el que se implementa un test E2E para verificar el proceso de inicio de sesión:

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.

El uso de tests E2E no reemplaza la necesidad de que miembros del equipo revisen la aplicación como usuarios. Ambos enfoques son complementarios.

¿Qué tipo de errores puede detectar la revisión humana?

¿Podemos encontrar una nueva forma de testear 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.