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

23

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?

Friki
fuente
13
Ese artículo fue escrito el miércoles 09 de agosto de 2000 (hace aproximadamente 12 años). No es que TDD no existiera en ese momento, pero no creo que haya disfrutado casi el rumor que tiene en estos días.
Mike
12
La prueba de Joel es solo un conjunto de pautas genéricas. No todo lo que "vale la pena" puede encajar allí.
Yannis
2
' Se me ocurrió mi propia prueba, muy irresponsable y descuidada para calificar la calidad de un equipo de software. Lo bueno de esto es que lleva unos 3 minutos ... Lo bueno de The Joel Test es que es fácil obtener un sí o un no rápido para cada pregunta. No tiene que averiguar las líneas de código por día o los errores promedio por punto de inflexión ... ' - decidir si su proyecto se beneficiará de TDD tomaría más de 3 minutos y, bueno , podría requerir calcular errores promedio por punto de inflexión , es por eso que no está en la lista
mosquito
Mover a Joel Stack por favor. Es una q interesante.
Erik Reppen
Debería considerar aceptar la respuesta que enlaza y cita directamente de Joel, ya que no tiene más autoridad que eso. Ver programmers.stackexchange.com/a/189493/6586
Bryan Oakley

Respuestas:

30

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 .

Karl Bielefeldt
fuente
1
Además ... oh, de alguna manera llegaste al TDD, ¿es Kool Aid punto no?
Erik Reppen
27

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.

Mason Wheeler
fuente
2
En realidad, tienes razón. El MO habitual de Joel es el hombre de paja. Al igual que TDD no habría detectado ningún error para mí, por lo que no puede ser bueno. Lo que de alguna manera pierde el punto de que TDD no se trata de pruebas, se trata de diseño. Las pruebas que quedan son una bonificación. O argumentar que un pequeño cambio romperá muchas pruebas unitarias, lo que sugiere que simplemente lo está haciendo mal. O reescribir completamente un principio SÓLIDO antes de atacarlo. Ese tipo de cosas. En realidad, son sus defensores los que usan la lógica circular, no él.
pdr
77
Estoy completamente de acuerdo con estos comentarios de Joel. Creo que un problema aún mayor es el lenguaje, con muchos lenguajes dinámicos que no puedo imaginar haciendo nada sin una prueba unitaria, ¿de qué otra manera puedes saber si un error tipográfico simple causará algún problema que no verás hasta que sea crítico? ¿momento? En lenguajes compilados de tipo estático diseñados para reducir los errores, se lo aleja de todos los errores más simples y se queda principalmente con errores lógicos. Esto reduce la necesidad del tipo de cobertura total proporcionada por TDD.
Bill K
2
@MasonWheeler: ¿Está discutiendo seriamente que la compilación / seguridad de tipo elimina la necesidad de pruebas unitarias? También ignora intencionalmente los beneficios de diseño de TDD pero, lo que es más importante, debe pasar un mal rato refactorizando cualquier cosa. Más bien, se ha visto lo contrario: por ejemplo, los desarrolladores de .NET que siguen una metodología TDD de repente se sienten frustrados por la cantidad de código que necesitan escribir para complacer a un compilador que a su vez es cada vez menos útil.
pdr
2
@pdr: Estoy argumentando seriamente que "la necesidad de pruebas unitarias" en primer lugar es la falta de seguridad de tipo. Y, al no ser un desarrollador de .NET, realmente no puedo decir mucho sobre sus experiencias, pero en mi propia experiencia he descubierto que la dificultad en la refactorización se basa completamente en dos factores: si escribí o no el código en el primero lugar, y si el autor escribió bien el código o no. (Nota: ¡los puntos 1 y 2 no están necesariamente estrechamente relacionados entre sí!)
Mason Wheeler
3
Las pruebas de unidad @Pdr no prueban su código, son principalmente un verificador de sintaxis, pero pueden ser muy útiles durante el desarrollo. Sin embargo, las pruebas de integración y sistema tienen mucho más sentido. Además, la mayoría de las refactorizaciones en lenguajes tipados estáticamente pueden demostrarse como seguras, de hecho, eso es una refactorización: un conjunto de operaciones "seguras" conocidas que transforman su código sin introducir cambios. En un lenguaje estático, el IDE a menudo puede hacer estos cambios por usted y asegurarse de que sean seguros, algo a menudo imposible en lenguajes dinámicos que, por lo tanto, requieren pruebas unitarias para ayudar con (no demostrar) la misma seguridad
Bill K
25

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.

Ross Patterson
fuente
2
De Verdad? ¿Votos negativos al publicar la propia respuesta de Joel a la pregunta del OP?
Ross Patterson
1
Difícil de entender. Algunas personas usan el voto para decir "apruebo" en lugar de "esto es útil". Obviamente, esta debería ser la respuesta aceptada porque es definitiva.
Bryan Oakley
Nunca he trabajado en un proyecto que tuviera una cobertura de prueba del 100%. Pero si tiene una cobertura de prueba del 0% ... ... eso es bastante revelador.
Kzqai
¡Gracias! Creo que esto debería marcarse como respuesta aceptada.
Jalal
5

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.

Martín
fuente
3
"¿Haces TDD?" ciertamente cabe como una pregunta de sí-no. Y con eso quiero decir que es una pregunta que todos responden con un rotundo "sí", que en realidad significa "no".
Yannis
2
@YannisRizos: Al igual que "¿Utiliza las mejores herramientas que el dinero puede comprar?" (Sí ... bien ... dentro de lo razonable.) Y "¿Los programadores tienen condiciones de trabajo tranquilas?" (Ohhhh sí ... bueno ... depende de tu punto de referencia para la tranquilidad, supongo.)
pdr
@pdr Depende de si considera silencioso el sonido de las sirenas que entran por ventanas abiertas.
Robert Harvey
Además, "Sí, hago diseño de arriba hacia abajo ". ;)
Izkata