Lección 131: Introducción al testing: por qué hace falta

Imagínate un mundo donde los desarrolladores escriben código y siempre funciona a la perfección. ¿Suena fantástico? Por desgracia, esa realidad no existe: los errores son inevitables. Nuestra tarea no es solo escribir código bonito, sino asegurarnos de que funciona como se espera.

Objetivos principales del testing:

1. Reducir la probabilidad de bugs. Incluso un desarrollador con experiencia puede cometer un fallo. Los tests ayudan a detectarlos y arreglarlos antes de que el código llegue a producción.
2. Asegurar la calidad de la aplicación. La aplicación debe comportarse de forma predecible. Nadie quiere que el botón "finalizar pedido" de repente empiece a borrar usuarios.
3. Confianza al hacer cambios. Cuando añadís nueva funcionalidad, los tests permiten comprobar que el código antiguo sigue funcionando correctamente.
4. Ahorro de tiempo en testing manual. Si cada vez tenéis que revisar la aplicación manualmente, os acabaréis agotando. Los tests automatizan ese proceso.

Tipos de testing

Ahora vamos a ver qué tipos de testing existen y para qué sirven.

Unit tests

• Son tests para componentes individuales de la aplicación, normalmente funciones o métodos.
• Están aislados del resto del sistema y no requieren interacción con recursos externos (por ejemplo, una base de datos).
• Los Unit tests son rápidos y baratos de escribir.

Integration tests

• Comprueban cómo distintos componentes de la aplicación trabajan juntos.
• Aquí interactuamos con recursos reales, como bases de datos o APIs externas.
• No están tan aislados como los Unit tests, pero dan una idea real de cómo funciona el sistema.

Functional tests

• Verifican el funcionamiento de una funcionalidad concreta desde la perspectiva del usuario.
• Por ejemplo, testear el flujo de pago desde que se añade al carrito hasta recibir la confirmación.
• A menudo requieren herramientas automatizadas para simular acciones del usuario.

System tests

• Prueban la aplicación completa, como un sistema único.
• Detectan problemas de configuración, integración e interacción entre todas las partes del sistema.

La pirámide del testing

Para organizar los tests a menudo se usa la pirámide del testing:

/ Functional Tests \
/---------------------\
/  Integration Tests   \
/-----------------------\
/      Unit Tests        \

• La base de la pirámide — Unit tests (~70% de los tests). Son los más baratos y rápidos, por eso hay más.
• El nivel intermedio — Integration tests (~20%). Comprueban la interacción entre componentes.
• La cúspide de la pirámide — Functional tests (~10%). Son más costosos de montar, por eso se escriben menos.

La pirámide sigue el principio velocidad-calidad-coste. Cuanto más arriba en la pirámide, más esfuerzo hace falta, pero más cobertura obtienes.

¿Dónde y cuándo escribimos tests?

Cuanto antes, mejor

Cuanto antes se detecta un error, más barato es arreglarlo. Si un bug se detecta ya en producción, arreglarlo es más difícil y puede afectar negativamente a los usuarios.

Por eso es importante escribir tests desde el inicio del desarrollo de una nueva funcionalidad. Este enfoque se llama TDD — Test Driven Development (desarrollo guiado por pruebas). Pero hablaremos más de esto en las siguientes lecciones.

Momento correcto

• Unit tests se escriben durante el desarrollo del método o la clase concreta.
• Integration tests se crean después de integrar todas las partes de la funcionalidad.
• Functional tests se añaden en la fase final de testing, antes de lanzar a producción.

Beneficio real de los tests. ¿Realmente hace falta?

Quizá alguno ya se pregunte: "¿No podemos prescindir de los tests? Al fin y al cabo, el QA lo comprobará todo". Buena pregunta. Vamos a aclararla.

1. Los testers de QA encontrarán defectos en la aplicación, pero su trabajo es validar el producto ya terminado. Los tests automatizados ayudan a los desarrolladores a detectar errores en etapas más tempranas.
2. Los tests reducen el riesgo. Tenéis la seguridad de que un cambio en una parte del código no romperá otra. Por ejemplo, si cambiáis la lógica de una API, vuestro Unit test os avisará si algo falla.
3. Aumentan la confianza. En desarrollo en equipo, tener tests permite que todos confiéis en la estabilidad del código.

Panorámica global

Imaginad un gran proyecto con varias equipos de desarrollo. Cada uno implementa su funcionalidad, hace cambios y arregla bugs. ¿Cómo asegurarse de que la aplicación funciona al final? La respuesta es obvia: mediante testing. Es como un seguro para los desarrolladores, que os da la tranquilidad de que todo va según lo previsto.

Lo que hemos aprendido hoy:

• Los tests son una parte necesaria del proceso de desarrollo y ahorran tiempo al buscar bugs.
• Hay varios tipos de tests, desde Unit tests hasta Functional tests.
• La pirámide del testing ayuda a distribuir el esfuerzo: más Unit tests, menos Functional tests.
• Los tests no solo tratan de bugs, sino de tener confianza en la calidad del producto.

En las siguientes lecciones nos meteremos en la implementación práctica del testing. Empezaremos escribiendo Unit tests sencillos usando JUnit 5 y conoceremos librerías potentes como Mockito, para luego pasar a integration tests. ¡Preparaos para ejemplos prácticos e interesantes!