1. Introducción

Cuando hablamos de testing nos referimos a pruebas empíricas para mejorar la calidad de nuestro código. Un conjunto de técnicas que evalúan la resistencia a los fallos de manera fehaciente.

A lo largo del curso usaré Python con la biblioteca pytest para ilustrar los ejemplos. No porque el testing sea cosa de Python, sino porque necesitamos un lenguaje concreto para bajar la teoría al suelo. Los patrones que verás son universales: sirven en cualquier lenguaje y con cualquier framework de pruebas. Si vienes de otro ecosistema, traduce la sintaxis y quédate con la idea.

{: .advice } Este es un curso de conceptos, no un manual de pytest. Si quieres profundizar en la herramienta, al final del curso te dejo un artículo dedicado solo a eso.

Existe una gran cantidad de enfoques y familias de pruebas. Vamos a ordenarlos.

Filosofías

• Desarrollo guiado por pruebas (TDD).
• Desarrollo guiado por el comportamiento (BDD).
• Diseño guiado por el dominio (DDD).

Pruebas dependiendo de la visibilidad

• Pruebas de caja blanca.
• Pruebas de caja gris.
• Pruebas de caja negra.

Pruebas dependiendo de la ejecución de las aplicaciones

• Pruebas estáticas.
• Pruebas dinámicas.

Pruebas funcionales

• Pruebas de unidad.
• Pruebas de integración.
• Pruebas de aceptación.
• Pruebas de extremo a extremo (E2E).

Pruebas no funcionales

• Pruebas de rendimiento.
• Pruebas de seguridad.
• Pruebas aleatorias (Fuzzing).

Pruebas según el número de pruebas a realizar

• Pruebas de humo (Smoke test).
• Pruebas de sanidad (Sanity Check).
• Pruebas de regresión/sistema (Regression test).

Si es un trabajo corto habrá una inversión de tiempo inicial, pero a medida que crezca el flujo aumentará la productividad al ser más lineal y controlado. Antes de que te digas "no voy a hacer testing porque es demasiado pequeño", quiero recordarte que todo proyecto empieza siendo pequeño. Después no encontrarás energías, será demasiado grande para testear o documentar.

¿Qué ventajas tiene hacer testing?

• Aumenta la calidad del proyecto y del código.
• Reduce los errores al añadir nuevas características.
• Menor tiempo a la hora de reparar errores.
• Incrementa el uso de buenas prácticas.

¿Contras?

• Incrementa el tiempo de desarrollo.
• Aumenta la complejidad.
• Muchos desarrolladores no tienen el hábito, por lo que existirá cierto rechazo al principio y necesidad de formación.
• Es difícil hacer testing de código viejo.

A cambio, la calidad de tu código no se verá comprometida. Si el cliente trabaja con tu aplicación no experimentará problemas técnicos. Tal vez no le termine de gustar el tamaño de un botón o el color de un texto, pero no llamará a tu puerta con una lista de errores. Y por consiguiente dormirás profundamente.

Pruebas de caja blanca

Son pruebas centradas en el código fuente, sabiendo qué introducimos y qué resultados esperamos. Siempre usando diferentes valores de entrada y conociendo de antemano los valores de vuelta.

Niveles

1. Prueba unitaria (Unit Testing): se prueba una función u objeto de forma individual.
2. Pruebas de integración (Integration Testing): se prueba un conjunto de funciones u objetos que interactúan entre ellos.
3. Pruebas de sistema (System Integration Testing): se prueba todo el software al completo.

Material de apoyo

Esquema flujo TDD

En el siguiente tema desarrollaremos las pruebas unitarias.