«¿Cuándo voy a terminar de escribir todo esto…?». Si ya vamos justos de tiempo para crear una sola función, que además nos pidan escribir pruebas hace suspirar a cualquiera.
La respuesta breve: la verdadera razón para escribir pruebas es proteger a tu yo del futuro. Dedicar 10 minutos más hoy evita una incidencia que estalle de madrugada dentro de 3 meses.
¿Por qué escribir pruebas?
La razón principal es que corregir código deja de dar miedo.
El código no se escribe una vez y se da por terminado. Se modifica continuamente y se le añaden funciones.
Sin pruebas, cada cambio de una línea genera inseguridad. «Si arreglo esto, ¿no se romperá otra cosa?»
Con pruebas, basta una ejecución para verificar el cambio. Si aparece verde, tranquilidad; si aparece rojo, ves enseguida qué se ha roto.
Esto se llama prueba de regresión: detecta cuando algo que funcionaba vuelve a romperse.
La verdadera razón para escribir pruebas aunque resulte tedioso
Sinceramente, las pruebas parecen una pérdida al principio. Al fin y al cabo, no añaden una función visible.
Pero la historia cambia a medida que crece el proyecto.
Cuando hay 30 o 50 funciones, es imposible comprobarlo todo a mano. No puedes hacer clic en todo cada vez que corriges algo.
Con pruebas, un solo comando permite validar docenas de casos en cuestión de segundos.
La segunda razón es que el código de prueba se convierte en documentación.
Unas pruebas bien escritas muestran de un vistazo qué resultado produce una función para cada entrada.
Los comentarios mienten cuando quedan obsoletos, pero las pruebas se ejecutan, así que no pueden mentir.
Veamos un ejemplo sencillo: una prueba para una función que calcula un descuento.
// 1una compra de diez mil wones 10% de descuento → 9debe dar mil wones
@Test func aplicar el_10porcentaje de_descuento() {
let result = applyDiscount(10000, rate: 0.1)
#expect(result == 9000)
}Con solo ver esta prueba, entiendes enseguida qué hace applyDiscount.
¿Cómo empezar con las pruebas?
Si intentas probarlo todo desde el principio, te agotarás y abandonarás.
Te recomiendo empezar así.
- Empieza por la lógica crítica cuyo fallo sería grave, como los cálculos monetarios y el inicio de sesión
- Funciones con muchas ramas condicionales que pueden resultar confusas
- Lugares donde ya ha aparecido un error, para evitar que se repita
En cambio, el código sencillo de la interfaz y las partes que cambian a menudo pueden esperar.
El objetivo no es probarlo todo al 100%, sino valorar el beneficio frente al coste.
Preguntas frecuentes
P. ¿Escribir pruebas ralentiza el desarrollo?
R. Al principio, sí. Pero a partir de la mitad del proyecto, en realidad acelera el desarrollo porque reduce mucho el tiempo de encontrar y corregir errores.
P. ¿Qué porcentaje de cobertura de pruebas es recomendable?
R. No hace falta obsesionarse con la cifra. Un 70–80% es suficiente; importa más que la lógica crítica esté cubierta.
El código de prueba no sirve para presumir de habilidad, sino como red de seguridad para tu yo futuro y tus compañeros.
Añade hoy una sola prueba a una función. Cuando sientas la tranquilidad que produce esa pequeña luz verde, entenderás por experiencia por qué todos recomiendan escribir pruebas.