Existe una obsesión peligrosa con alcanzar la cobertura total del código, pero debemos ser honestos: el 100% de cobertura es, a menudo, una métrica de vanidad. Obsesionarse con este número genera una burocracia técnica que no siempre añade valor real al usuario o al negocio.
El objetivo del testing no es pintar una gráfica de verde, sino darte la confianza necesaria para refactorizar o lanzar una funcionalidad un viernes por la tarde sin temor a que el sistema colapse. Como vimos en el primer día de este reto, si la perfección técnica (o la búsqueda de una métrica ideal) retrasa el valor que entregamos, estamos matando al negocio.
¿Qué deberías testear realmente?
Siguiendo los estándares de equipos de alto rendimiento como los de Angular y Flutter en Google, el testing debe centrarse en la estabilidad a largo plazo y la reducción de costos de mantenimiento. No todos los tests valen lo mismo, por eso un enfoque senior se divide así:
- Lógica de Negocio Crítica: Debes proteger los flujos donde se mueve el dinero o donde la lógica es tan compleja que un error humano es probable.
- Casos de Borde (Edge Cases): Un test de valor es aquel que prueba qué sucede cuando la API devuelve un error o el usuario envía datos inesperados, no el que prueba un simple «getter».
- Regresiones: Cada vez que encuentres y arregles un bug, escribe un test que asegure que ese error específico nunca más volverá a aparecer en producción.
El Testing como motor de velocidad
Lejos de ser un freno, un buen set de tests automatizados es el pedal del acelerador. Te da la libertad de cambiar la implementación interna de un módulo (refactorizar) con la seguridad de que el comportamiento externo sigue intacto.
Si el test se rompe solo porque cambiaste el «cómo» se hace algo, pero el «qué» (el resultado) sigue siendo el mismo, tienes un test frágil que debes corregir. El testing estratégico busca proteger el resultado, no la implementación.
Al final del día, el testing es una inversión en tu salud mental y en la rentabilidad del producto que construyes.
La diferencia entre Cobertura y Confianza
El objetivo del testing no es pintar una gráfica de verde, sino darte la confianza necesaria para desplegar a producción un viernes a las 5:00 PM sin temor a que el sistema colapse.
- Tests de Vanidad: Probar getters, setters o lógica trivial solo para subir el porcentaje de cobertura.
- Tests de Valor: Probar los flujos donde el dinero se mueve, donde la lógica de negocio es compleja y donde un error mataría al negocio (como vimos en el Día 1).
Fomentando una cultura de calidad (Estilo Google)
Siguiendo los estándares que vemos en Angular y Flutter, el testing debe ser parte intrínseca del desarrollo (TDD o no) porque reduce drásticamente el costo de mantenimiento a largo plazo.
- Unit Tests: Para la lógica pura y rápida.
- Integration Tests: Para asegurar que los módulos hablen el mismo idioma.
- E2E: Para proteger la experiencia final del usuario.
3. Checklist de Testing Estratégico
Si quieres fomentar el testing en tu equipo sin quemar el presupuesto, enfócate en estos 4 puntos:
- [ ] Lógica de Negocio Crítica: ¿Este test protege una funcionalidad por la que el cliente paga?.
- [ ] Casos de Borde (Edge Cases): ¿Probamos qué pasa cuando la API devuelve un error o el usuario envía datos nulos?.
- [ ] Regresiones de Bugs: Cada vez que arregles un bug, escribe un test que asegure que nunca más volverá a aparecer.
- [ ] Refactorización Segura: ¿Puedo cambiar la implementación interna sin que el test se rompa? Si el test se rompe al cambiar el «cómo» pero no el «qué», es un test frágil.
esto es una prueba