Qué no probar
Las pruebas que cuestan más de lo que dan: las cinco categorías que conviene no escribir, y por qué una suite más pequeña puede proteger más.
Las cinco categorías
La segunda es la que más daño hace a largo plazo: una suite que prueba la implementación convierte cada mejora del código en trabajo de arreglar pruebas, y a partir de cierto punto la gente deja de mejorar el código.
Por qué una suite grande puede proteger menos
Cuatro mecanismos, y los cuatro son reales:
El cuarto es el más peligroso porque es invisible: el número dice que estás cubierto y lo que falla es exactamente lo que no probaste.
El criterio que las une
Una pregunta, y decide las cinco categorías:
¿Esta prueba podría fallar por algo que ibas a publicar sin darte cuenta?
- Si sí: merece existir.
- Si solo puede fallar por algo que verías al instante —un envoltorio roto, un tipo equivocado— no.
- Y si puede fallar sin que nada esté mal —una refactorización, una imagen ligeramente distinta— hace más daño que bien.
Podar
Y qué hacer con una suite que ya tiene de las cinco:
- Quita las que fallan intermitentemente. Nivel 71.4: arreglarlas o quitarlas, nunca dejarlas.
- Quita las que no han fallado nunca por un motivo real y prueban algo trivial.
- Reescribe las de implementación en términos de comportamiento, si lo que prueban importa.
- Y mide el tiempo antes y después: si la suite baja de minutos a segundos, has ganado más de lo que perdiste.
Y una nota: podar una suite se siente mal —parece perder trabajo— y es una mejora. Nivel 56.3, aplicado a las pruebas.