¿Por qué falta el desarrollo impulsado por la prueba de Joel's Test?

Estaba leyendo este blog de Joel Spolsky sobre 12 pasos para mejorar el código . La ausencia de Test Driven Development realmente me sorprendió. Entonces quiero lanzar la pregunta a los Gurus. ¿TDD realmente no vale la pena el esfuerzo?

El desarrollo impulsado por pruebas era prácticamente desconocido antes de que el libro de Kent Beck saliera en 2002, dos años después de que Joel escribiera esa publicación. Entonces, la pregunta es por qué Joel no ha actualizado su prueba, o si TDD hubiera sido mejor conocido en 2000, ¿lo habría incluido entre sus criterios?

Creo que no lo habría hecho, por la sencilla razón de que lo importante es que tienes un proceso bien definido, no los detalles específicos de ese proceso. Es la misma razón por la que recomienda el control de versiones sin especificar un sistema de control de versiones específico, o recomienda tener una base de datos de errores sin recomendar una marca específica. Los buenos equipos mejoran y se adaptan continuamente, y utilizan herramientas y procesos que se adaptan bien a su situación particular en ese momento en particular. Para algunos equipos, eso definitivamente significa TDD. Para otros equipos, no tanto. Si adoptas TDD, asegúrate de que no esté fuera de una mentalidad de culto de carga .

Joel realmente ha abordado esto específicamente en algunos lugares.

Explicó que las pruebas de cosas no son capaces de atrapar muchos problemas importantes, particularmente subjetivos como "¿la interfaz de usuario de este software apesta?" Según él, la excesiva dependencia de las pruebas automatizadas en Microsoft es la forma en que terminamos con Windows Vista.

Ha escrito cómo, en su experiencia, los tipos de errores que los usuarios encuentran tienden a clasificarse en dos categorías: 1) los que se muestran en el uso común, que los programadores habrían encontrado si hubieran ejecutado su propio código antes de usarlo , o 2) casos extremos tan oscuros que nadie hubiera pensado escribir pruebas para cubrirlos en primer lugar. Él ha declarado que solo un porcentaje muy pequeño de los errores que él y su equipo arreglan en FogBugz son el tipo de cosa que las pruebas unitarias habrían detectado. (No puedo encontrar ese artículo ahora, pero si alguien sabe a qué me refiero, siéntase libre de editar el enlace aquí).

Y ha escrito cómo puede ser más problemático de lo que vale, especialmente cuando su proyecto se convierte en un proyecto muy grande con muchas pruebas unitarias, y luego cambia algo (intencionalmente) y termina con una gran cantidad de pruebas unitarias rotas. Él usa específicamente los problemas que las pruebas unitarias pueden causar como la razón por la cual no lo ha agregado como un punto 13 a la Prueba de Joel, incluso cuando las personas sugieren que debería hacerlo.

El mismo Joel Spolsky respondió esta pregunta en 2009 :

Joel: Hay un debate sobre Test Driven Development ... si tienes pruebas unitarias para todo, ese tipo de cosas ... mucha gente me escribe, después de leer The Joel Test, para decir: "Deberías tener un 13 aquí: Pruebas unitarias, 100% pruebas unitarias de todo su código ".

Y eso me parece un poco demasiado doctrinario sobre algo que quizás no necesites. Como, la idea de la programación ágil no es hacer cosas antes de que las necesites, sino criticarlas según sea necesario. Siento que las pruebas automáticas de todo, muchas veces, simplemente no te ayudarán. En otras palabras, vas a escribir una gran cantidad de pruebas unitarias para asegurarte de que el código realmente va a funcionar, y definitivamente vas a descubrir si no funciona [si no lo haces escribir las pruebas] funciona, en realidad todavía funciona, ... No sé, voy a recibir un correo de este tipo porque no lo expreso tan bien. Pero, siento que si un equipo realmente tuviera una cobertura del 100% del código de sus pruebas unitarias, habría un par de problemas. Uno, habrían pasado mucho tiempo escribiendo pruebas unitarias, y no necesariamente podrían pagar ese tiempo con una mejor calidad. Quiero decir, tendrían algo de calidad mejorada y tendrían la capacidad de cambiar las cosas en su código con la confianza de que no romperían nada, pero eso es todo.

Pero el verdadero problema con las pruebas unitarias, como he descubierto, es que el tipo de cambios que tiende a realizar a medida que el código evoluciona tiende a romper un porcentaje constante de sus pruebas unitarias. A veces, hará un cambio en su código que, de alguna manera, rompe el 10% de sus pruebas unitarias. Intencionalmente. Porque has cambiado el diseño de algo ... has movido un menú, y ahora todo lo que dependía de ese menú estaba allí ... el menú ahora está en otra parte. Y entonces todas esas pruebas ahora se rompen. Y debe poder entrar y recrear esas pruebas para reflejar la nueva realidad del código.

Entonces, el resultado final es que, a medida que su proyecto se hace más y más grande, si realmente tiene muchas pruebas unitarias, la cantidad de inversión que tendrá que hacer para mantener esas pruebas unitarias, mantenerlas actualizadas y mantenerlas cuando pasan, comienza a ser desproporcionado con respecto a la cantidad de beneficio que obtiene de ellos.

Nadie más que Joel podría responder eso con seguridad. Pero podemos probar algunas razones / observaciones.

En primer lugar, la prueba no está ausente de la prueba de Joel

• Las pruebas se mencionan dos veces en 12 pasos directamente (10 y 12)
• La existencia de una construcción es uno de los primeros puntos. La idea de tener una compilación es obtener la capacidad de ver si se rompen, por lo que (también) estamos hablando de probar aquí.

En segundo lugar, la idea de la prueba de Joel (según tengo entendido) es tener preguntas rápidas, sí, no. "¿Haces TDD?" no encajará exactamente (la respuesta podría ser: "algunos de nosotros", "para esa parte del código" o "hacemos pruebas unitarias".

En tercer lugar, creo que nadie dijo eso (incluso Joel) que esos puntos en los que "los únicos que valen la pena" (por cierto, "¿programa usted?" No están en él), solo que esas son buenas preguntas rápidas para hacer al llegar en contacto con un equipo de software, ya sea como futuro miembro del equipo o incluso como cliente: esta es una lista que le di a algunas personas no técnicas a mi alrededor que estaban buscando pistas sobre qué tan bueno / malo era su propio departamento de TI. No es todo, pero es realmente malo vencer en tres minutos.