Perdiendo la fe en las pruebas

Papel de las pruebas frente al diseño

• Muchos sostienen que las pruebas no pueden salvar una arquitectura fundamentalmente mala; la simplificación y la comprensibilidad importan más.
• Otros informan éxito usando pruebas de integración para primero “envolver” un desastre heredado, y luego refactorizarlo con seguridad, viendo las pruebas como un facilitador de la simplificación en lugar de un sustituto.
• Las pruebas se describen como una herramienta para la confianza y el cambio, no como una garantía de corrección.

Dónde las pruebas aportan un alto valor

• Los componentes centrales, estables y que soportan carga (VMs, bases de datos, lógica de negocio central) se benefician enormemente de pruebas extensas y fuzzing.
• Las pruebas de integración y de extremo a extremo son elogiadas por detectar errores reales entre sistemas y permitir refactors sin miedo, especialmente en sistemas con múltiples servicios y gran carga de infraestructura.
• Las pruebas son valiosas para actualizar bibliotecas/frameworks, prevenir regresiones y preservar el comportamiento cuando los autores originales se marchan.
• Las pruebas basadas en propiedades y las suites sólidas se presentan como un “endurecimiento para la batalla” para sistemas maduros.

Dónde las pruebas se ven con bajo retorno de inversión

• Las funciones de producto que cambian rápido y el pulido de la interfaz en startups en fase inicial pueden sobreprobarse, matando la velocidad y llevando a suites frágiles que fallan constantemente.
• Las herramientas interactivas (editores de texto, terminales) pueden salirse con menos pruebas automatizadas si las rutas principales se ejercitan continuamente con el uso.
• Algunos equipos informan haber lanzado productos aceptables con poca automatización, apoyándose en pruebas manuales, métricas, despliegues canary y rollbacks.

Problemas culturales y de proceso

• A menudo las pruebas se tratan como una religión: objetivos de cobertura, dogma de TDD y pruebas obligatorias para cada línea producen suites pesadas en mocks y de poco valor.
• La ley de Goodhart: la cobertura como KPI lleva a pruebas triviales o redundantes que no mejoran la calidad pero sí ralentizan el cambio.
• Los incentivos (rendimiento por tickets, falta de tiempo) empujan a los desarrolladores hacia “una porquería improvisada”; se critica culpar a individuos en lugar de a los sistemas.

Alternativas, complementos y estrategias

• Los sistemas de tipos fuertes eliminan muchas clases de errores y reducen las pruebas necesarias, pero no las reemplazan; los tipos y las pruebas se ven como complementarios.
• Las pruebas manuales exploratorias siguen considerándose cruciales para problemas de UX, sorpresas de rendimiento e interacciones imprevistas.
• Varios comentaristas abogan por tratar las pruebas como inversiones: centrarse en escenarios de alto valor, invariantes centrales y protección contra regresiones; mantener suites rápidas, con pocas fluctuaciones, y estar dispuestos a eliminar o evitar pruebas de bajo ROI.