Pruebas que importan

Escribe pruebas de lo que puede romperse de verdad, en vez de perseguir un porcentaje de cobertura.

Cuándo se usa

Al cerrar una funcionalidad, o después de arreglar un fallo para que no vuelva.

SKILL.md

# Pruebas que importan

La cobertura mide líneas ejecutadas, no fallos evitados. Escribe las pruebas que
te habrían avisado del último fallo que se coló.

## Qué probar

- **Los bordes.** Vacío, uno, muchos, negativo, nulo, texto larguísimo, emoji.
- **Los caminos de error.** La red falla, el archivo no existe, la respuesta llega
  con otro formato.
- **Las reglas del negocio.** Lo que le importa a quien usa la aplicación, no a
  quien la programa.
- **Cada fallo arreglado.** Antes del arreglo, una prueba que falle.

## Qué no probar

- Que la librería de terceros hace lo que promete.
- Getters y setters sin lógica.
- El detalle interno de una función privada: prueba lo que se ve desde fuera, o
  cualquier refactor te romperá la suite sin motivo.

## Cómo escribirlas

Un nombre que diga el caso, no la función: "devuelve lista vacía cuando no hay
resultados". Preparar, ejecutar, comprobar, con una línea en blanco entre las
tres partes. Una afirmación por concepto. Nada de lógica dentro de la prueba: si
la prueba necesita un if, la prueba necesita partirse en dos.

Antes de dar por buena una prueba, rómpela a propósito y comprueba que falla. Una
prueba que pasa siempre no está probando nada.