|
El otro día me pasaron un documento de 2014 de James Copelien que tenía un título similar al de este email. En el documento viene a decir que los test unitarios tuvieron mucho sentido en los inicios de la programación, pero que con la programación orientada a objetos y su naturaleza dinámica habían dejado de tener eficacia. Hace 11 años de este artículo y eso que no había el auge de aplicaciones móviles, aplicaciones front-end o microservicios de la actualidad. ¿Qué opino de artículo? Pues en parte estoy de acuerdo. No tiene sentido alguno crear tests para cada clase o función de tu proyecto. Si haces eso, cada línea de código de producción que cambies va a romper los tests. Vas a pasar más tiempo arreglando tests que solucionando los problemas de tu cliente. Tener miles de tests unitarios que se rompen porque cambie un punto y coma, no te va a dar la confianza y seguridad en tu proyecto. Pero algunos tests unitarios sí son necesarios. La clave es saber cuáles si son necesarios y cuáles no. Además de saber qué otro tipo de testing necesita tu aplicación dado su contexto. Hay una forma más inteligente de escribir tests y es lo que te enseño a hacer en mi Máster class Testing Basado en Pilares. Si compras antes del lunes 24 a las 11:00 (hora España) te llevas un nuevo audio de preguntas y respuestas de regalo. Hay preguntas que me han hecho que son realmente buenas. Master Class - Testing Basado en Pilares PD: El bonus de preguntas y respuestas de regalo es si compras antes de que lo envíe el lunes 24 a las 11:00 (hora España).
|