Desventajas del Desarrollo Impulsado por Pruebas? [cerrado]

Si quieres hacer TDD "real" (léase: prueba primero con los pasos rojo, verde, refactor) entonces también tienes que empezar a usar simks/stubs, cuando quieras probar puntos de integración.

Cuando empiece a usar burlas, después de un tiempo, querrá comenzar a usar Inyección de Dependencias (DI) y un contenedor de Inversión de Control (IoC). Para ello es necesario utilizar interfaces para todo (que tienen una gran cantidad de trampas a sí mismos).

Al final del día, tienes que escribir mucho más código, que si lo haces de la"manera normal". En lugar de solo una clase de cliente, también necesita escribir una interfaz, una clase simulada, alguna configuración de IoC y algunas pruebas.

Y recuerde que el código de prueba también debe mantenerse y cuidarse. Las pruebas deben ser tan legibles como todo lo demás y se necesita tiempo para escribir un buen código.

Muchos desarrolladores no entienden cómo hacer todo esto "de la manera correcta". Pero porque todo el mundo les dice que TDD es la única manera verdadera de desarrollar software, solo intentan lo mejor que pueden.

Es mucho más difícil de lo que uno podría pensar. A menudo los proyectos realizados con TDD terminan con una gran cantidad de código que nadie entiende realmente. Las pruebas unitarias a menudo prueban lo incorrecto, de la manera incorrecta. Y nadie está de acuerdo en cómo debería ser una buena prueba, ni siquiera los llamados gurús.

Todas esas pruebas hacen que sea mucho más difícil "cambiar" (opuesto a la refactorización) el comportamiento de su sistema y los cambios simples se vuelven demasiado difíciles y el tiempo consumir.

Si lee la literatura TDD, siempre hay algunos ejemplos muy buenos, pero a menudo en aplicaciones de la vida real, debe tener una interfaz de usuario y una base de datos. Aquí es donde el TDD se pone realmente difícil, y la mayoría de las fuentes no ofrecen buenas respuestas. Y si lo hacen, siempre implica más abstracciones: objetos simulados, programación en una interfaz, patrones MVC / MVP, etc., que de nuevo requieren mucho conocimiento, y... tienes que escribir aún más código.

Así que ten cuidado... si no tienes un equipo entusiasta y al menos un desarrollador experimentado que sabe cómo escribir buenas pruebas y también sabe algunas cosas sobre buena arquitectura, realmente tienes que pensar dos veces antes de ir por el camino TDD.

Cuando llegue al punto en el que tenga un gran número de pruebas, cambiar el sistema podría requerir volver a escribir algunas o todas sus pruebas, dependiendo de cuáles fueron invalidadas por los cambios. Esto podría convertir una modificación relativamente rápida en una que consume mucho tiempo.

Además, puede comenzar a tomar decisiones de diseño basadas más en TDD que en prinicipals de diseño realmente buenos. Mientras que es posible que haya tenido una solución muy simple y fácil que es imposible probar la forma en que TDD demandas, ahora tiene un sistema mucho más complejo que en realidad es más propenso a errores.

Creo que el mayor problema para mí es la ENORME pérdida de tiempo que lleva "entrar en él". Todavía estoy muy al comienzo de mi viaje con TDD (Ver mi blog para actualizaciones mis aventuras de prueba si estás interesado) y literalmente he pasado horas empezando.

Lleva mucho tiempo poner a tu cerebro en "modo de prueba" y escribir "código comprobable" es una habilidad en sí misma.

TBH, respetuosamente no estoy de acuerdo con Los comentarios de Jason Cohen sobre hacer públicos los métodos privados, no se trata de eso. No he hecho más métodos públicos en mi nueva forma de trabajar que antes . Sin embargo, implica cambios arquitectónicos y le permite "conectar en caliente" módulos de código para que todo lo demás sea más fácil de probar. Deberías no hacer que las partes internas de tu código sean más accesibles para hacer esto. De lo contrario, estamos de vuelta al punto de partida con todo siendo público, ¿dónde está la encapsulación en eso?

So, (IMO) in a en pocas palabras:

• La cantidad de tiempo necesario para pensar (es decir, realmente grok'ing probando).
• El nuevo conocimiento requerido para saber escribir código comprobable.
• Comprender los cambios arquitectónicos necesarios para hacer que el código sea comprobable.
• Aumentando tu habilidad de "TDD-Coder" mientras intentas mejorar todas las demás habilidades requeridas para nuestro glorioso arte de programación:)
• Organizar su base de código para incluir código de prueba sin atornillar su código de producción.

  ---

PD: Si desea enlaces a aspectos positivos, he hecho y respondido varias preguntas al respecto, consulte mi perfil .

En los pocos años que he estado practicando el Desarrollo Impulsado por Pruebas, tendría que decir que las mayores desventajas son:

Venderlo a la gerencia

El TDD se realiza mejor en pares. Por un lado, es difícil resistir el impulso de simplemente escribir la implementación cuando SABE cómo escribir una instrucción if/else. Pero un par te mantendrá en la tarea porque tú lo mantienes en la tarea. Lamentablemente, muchas empresas / gerentes no piensan que este es un buen uso de los recursos. Por qué pagar dos personas para escribir una característica, cuando tengo dos características que deben hacerse al mismo tiempo?

Vendiéndolo a otros desarrolladores

Algunas personas simplemente no tienen la paciencia para escribir pruebas unitarias. Algunos están muy orgullosos de su trabajo. O, a algunos les gusta ver métodos/funciones enrevesados que se borran del final de la pantalla. TDD no es para todos, pero realmente desearía que lo fuera. Sería mucho más fácil mantener las cosas para esas pobres almas que heredan codificar.

Mantener el código de prueba junto con su código de producción

Idealmente, sus pruebas solo se romperán cuando tome una mala decisión de código. Es decir, pensabas que el sistema funcionaba de una manera, y resulta que no. Rompiendo una prueba, o un (pequeño) conjunto de pruebas, esto es realmente una buena noticia. Sabes exactamente cómo afectará tu nuevo código al sistema. Sin embargo, si sus pruebas están mal escritas, estrechamente acopladas o, peor aún, generadas (tos VS Prueba), a continuación, mantener sus pruebas puede convertirse en un coro rápidamente. Y, después de suficientes pruebas comienzan a causar más trabajo que el valor percibido que están creando, entonces las pruebas serán lo primero que se eliminará cuando los horarios se comprimen (por ejemplo. se llega a tiempo de crunch)

Escribir pruebas para que cubra todo (100% de cobertura de código)

Idealmente, de nuevo, si se adhiere a la metodología, su código será 100% probado por defecto. Normalmente, pensé, termino con cobertura de código superior al 90%. Esto suele suceder cuando tengo una arquitectura de estilo de plantilla, y la base se prueba, y trato de cortar esquinas y no probar las personalizaciones de la plantilla. Además, he descubierto que cuando me encuentro con una nueva barrera que no había encontrado anteriormente, tengo una curva de aprendizaje en las pruebas. Admitiré haber escrito algunas líneas de código a la manera de la vieja escuela, pero realmente me gusta tener ese 100%. (Supongo que era un triunfador en la escuela, er skool).

Sin embargo, con eso diría que los beneficios de TDD superan con creces los negativos de la simple idea de que si puedes lograr un buen conjunto de pruebas que cubran tu aplicación pero no sean tan frágiles que un cambio las rompa todas, podrás seguir agregando nuevas características el día 300 de tu proyecto como lo hiciste el día 1. Esto no sucede con todos aquellos que prueban TDD pensando que es una bala mágica para todo su código plagado de errores, y por lo que piensan que no puede funcionar, y punto.

Personalmente he encontrado que con TDD, escribo código más simple, paso menos tiempo debatiendo si una solución de código en particular funcionará o no, y que no tengo miedo de cambiar cualquier línea de código que no cumpla con los criterios establecidos por el equipo.

TDD es una disciplina difícil de dominar, y he estado en ella durante unos años, y todavía aprendo nuevas técnicas de prueba todo el tiempo. Es una gran inversión de tiempo por adelantado, pero, a largo plazo, su sostenibilidad será mucho mayor que si no tuviera pruebas unitarias automatizadas. Ahora, si mis jefes pudieran resolver esto.

En tu primer proyecto TDD hay dos grandes pérdidas, tiempo y libertad personal

Pierdes tiempo porque:

• Crear un conjunto completo, refactorizado y mantenible de pruebas de unidad y aceptación agrega mucho tiempo a la primera iteración del proyecto. Esto puede ser tiempo ahorrado a largo plazo, pero igualmente puede ser tiempo que no tiene que gastar.
• Debe elegir y convertirse en experto en un conjunto básico de herramientas. Una herramienta de prueba unitaria necesita ser complementada por algún tipo de marco burlón y ambos necesitan convertirse en parte de su sistema de compilación automatizado. También desea seleccionar y generar métricas apropiadas.

Pierdes la libertad personal porque:

• TDD es una forma muy disciplinada de escribir código que tiende a frotar raw contra aquellos en la parte superior e inferior de la escala de habilidades. Escribir siempre código de producción de cierta manera y someter tu trabajo a una revisión continua por pares puede asustar a tus peores y mejores desarrolladores e incluso provocar pérdidas de plantilla.
• La mayoría de los métodos ágiles que incorporan TDD requieren que hable con el cliente continuamente sobre lo que se propone lograr (en esta historia/día/lo que sea) y cuáles son las compensaciones. Una vez más, esto no es la taza de té de todos, tanto en el lado de los desarrolladores de la cerca como en los clientes.

Espero que esto ayude

TDD requiere que planifiques cómo funcionarán tus clases antes de escribir código para pasar esas pruebas. Esto es a la vez un más y un menos.

Me resulta difícil escribir pruebas en un "vacío" before antes de que se haya escrito ningún código. En mi experiencia tiendo a tropezar con mis exámenes cada vez que inevitablemente pienso en algo mientras escribo mis clases que olvidé al escribir mis exámenes iniciales. Entonces es hora no solo de refactorizar mis clases, sino TAMBIÉN mis pruebas. Repita esto tres o cuatro veces y puede ser frustrante.

Prefiero escribir un borrador de mis clases primero y luego escribir (y mantener) una batería de pruebas unitarias. Después de tener un borrador, TDD funciona bien para mí. Por ejemplo, si se informa de un error, escribiré una prueba para explotar ese error y luego corregiré el código para que la prueba pase.

La creación de prototipos puede ser muy difícil con TDD - cuando no está seguro de qué camino va a tomar hacia una solución, escribir las pruebas por adelantado puede ser difícil (aparte de las muy amplias). Esto puede ser un dolor.

Honestamente, no creo que para el "desarrollo central" para la gran mayoría de los proyectos haya ningún inconveniente real, sin embargo; se habla mucho más de lo que debería ser, generalmente por personas que creen que su código es lo suficientemente bueno como para no necesitar pruebas (nunca lo es) y la gente que simplemente no puede molestarse en escribirlos.

Bueno, y este estiramiento, necesita depurar sus pruebas. Además, hay un cierto costo en el tiempo para escribir las pruebas, aunque la mayoría de la gente está de acuerdo en que es una inversión inicial que vale la pena durante la vida útil de la aplicación, tanto en la depuración de tiempo ahorrado y en la estabilidad.

El mayor problema que he tenido personalmente con él, sin embargo, es conseguir la disciplina para escribir realmente las pruebas. En un equipo, especialmente en un equipo establecido, puede ser difícil convencerlos de que el tiempo gastado vale la pena.

Pierdes la habilidad de decir que has "terminado" antes de probar todo tu código.

Se pierde la capacidad de escribir cientos o miles de líneas de código antes de ejecutarlo.

Pierdes la oportunidad de aprender a través de la depuración.

Pierdes la flexibilidad para enviar código de la que no estás seguro.

Se pierde la libertad de acoplar estrechamente los módulos.

Pierde la opción de omitir la escritura de documentación de diseño de bajo nivel.

Se pierde la estabilidad que viene con un código que todo el mundo tiene miedo de cambiar.

Pierdes el título de "hacker".

Si sus pruebas no son muy exhaustivas, podría caer en una falsa sensación de que "todo funciona" solo porque sus pruebas pasan. Teóricamente si sus pruebas pasan, el código está funcionando; pero si pudiéramos escribir código perfectamente la primera vez no necesitaríamos pruebas. La moraleja aquí es asegurarse de hacer un chequeo de cordura por su cuenta antes de llamar a algo completo, no solo confíe en las pruebas.

En esa nota, si su comprobación de cordura encuentra algo que no se ha probado, asegúrese de volver y escribe una prueba para ello.

La desventaja de TDD es que generalmente está estrechamente asociada con la metodología 'Ágil', que coloca no importancia en la documentación de un sistema, más bien la comprensión detrás de por qué una prueba 'debería' devolver un valor específico en lugar de cualquier otro reside solo en la cabeza del desarrollador.

Tan pronto como el desarrollador se va u olvida la razón por la que la prueba devuelve un valor específico y no otro, estás jodido. TDD está bien SI está adecuadamente documentado y rodeado de legible por humanos (es decir. gestor de pelo puntiagudo) documentación a la que se puede hacer referencia en 5 años cuando el mundo cambie y tu aplicación también lo necesite.

Cuando hablo de documentación, esto no es un blurb en código, esto es escritura oficial que existe externa a la aplicación, como casos de uso e información de antecedentes que pueden ser referidos por gerentes, abogados y el pobre sap que tiene que actualizar su código en 2011.

Me he encontrado con varias situaciones en las que TDD me vuelve loco. Para nombrar algunos:

• Mantenimiento del caso de prueba:

  Si usted está en una gran empresa, muchas posibilidades son que usted no tiene que escribir los casos de prueba usted mismo o al menos la mayoría de ellos están escritos por otra persona cuando entra en la empresa. Las características de una aplicación cambian de vez en cuando y si no tiene un sistema en su lugar, como HP Quality Center, para rastrearlas, se volverá loco en no tiempo.

  Esto también significa que a los nuevos miembros del equipo les tomará bastante tiempo captar lo que está pasando con los casos de prueba. A su vez, esto puede traducirse en más dinero necesario.

• Complejidad de la automatización de pruebas:

  Si automatiza algunos o todos los casos de prueba en scripts de prueba ejecutables por máquina, tendrá que asegurarse de que estos scripts de prueba estén sincronizados con sus correspondientes casos de prueba manuales y en línea con los cambios de la aplicación.

  También, dedicarás tiempo a depurar los códigos que te ayudan a detectar errores. En mi opinión, la mayoría de estos errores provienen del fracaso del equipo de pruebas para reflejar los cambios de la aplicación en el script de prueba de automatización. Los cambios en la lógica de negocio, la interfaz gráfica de usuario y otras cosas internas pueden hacer que sus scripts dejen de ejecutarse o se ejecuten de forma poco fiable. A veces los cambios son muy sutiles y difíciles de detectar. Una vez que todos mis scripts reportan fallas porque basaron su cálculo en la información de la tabla 1, mientras que la tabla 1 era ahora tabla 2 (porque alguien intercambió el nombre de los objetos de la tabla en el código de la aplicación).

El mayor problema son las personas que no saben cómo escribir pruebas unitarias adecuadas. Escriben pruebas que dependen unas de otras (y funcionan muy bien corriendo con Ant, pero luego de repente fallan cuando las corro desde Eclipse, solo porque se ejecutan en un orden diferente). Escriben pruebas que no prueban nada en particular, simplemente depuran el código, comprueban el resultado y lo convierten en prueba, llamándolo "test1". Amplían el alcance de las clases y métodos, solo porque será más fácil escribe pruebas unitarias para ellos. El código de las pruebas unitarias es terrible, con todos los problemas de programación clásicos (acoplamiento pesado, métodos que tienen 500 líneas de largo, valores codificados, duplicación de código) y es un infierno para mantener. Por alguna extraña razón la gente trata las pruebas unitarias como algo inferior al código" real", y no les importa su calidad en absoluto. :-(

Pierdes mucho tiempo escribiendo pruebas. Por supuesto, esto podría ser salvado al final del proyecto mediante la captura de errores más rápido.

El mayor inconveniente es que si realmente quieres hacer TDD correctamente, tendrás que fallar mucho antes de tener éxito. Dado el número de empresas de software de trabajo (dólar por KLOC) que eventualmente será despedido. Incluso si su código es más rápido, más limpio, más fácil de mantener y tiene menos errores.

Si está trabajando en una empresa que le paga por los KLOCs (o requisitos implementados even incluso si no se prueban), manténgase alejado de TDD (o revisiones de código, o programación de pares, o Integración Continua, etc. sucesivamente. sucesivamente.).

Secundo la respuesta sobre el tiempo de desarrollo inicial. También pierde la capacidad de trabajar cómodamente sin la seguridad de las pruebas. También me han descrito como un nutbar TDD, por lo que podría perder algunos amigos;)

Reenfocarse en requisitos difíciles e imprevistos es la pesadilla constante del programador. El desarrollo basado en pruebas te obliga a centrarte en los requisitos mundanos ya conocidos y limita tu desarrollo a lo que ya se ha imaginado.

Piénselo, es probable que termine diseñando casos de prueba específicos, por lo que no se volverá creativo y comenzará a pensar "sería genial si el usuario pudiera hacer X, Y y Z". Por lo tanto, cuando ese usuario comienza a emocionarse posibles requisitos de enfriamiento X, Y y Z, su diseño puede estar demasiado rígidamente enfocado en casos de prueba ya especificados, y será difícil de ajustar.

Esto, por supuesto, es una espada de doble filo. Si pasas todo tu tiempo diseñando para cada concebible, imaginable, X, Y y Z que un usuario pueda desear, inevitablemente nunca completarás nada. Si usted completa algo, será imposible para cualquier persona (incluido usted mismo) tener alguna idea de lo que está haciendo en su código/diseño.

Se percibe como más lento. A largo plazo, eso no es cierto en términos del dolor que te ahorrará en el futuro, pero terminarás escribiendo más código, por lo que podría decirse que estás gastando tiempo en "probar no codificar". Es un argumento defectuoso, ¡pero preguntaste!

Puede ser difícil y llevar mucho tiempo escribir pruebas para datos "aleatorios" como fuentes XML y bases de datos (no tan difíciles). He pasado algún tiempo últimamente trabajando con fuentes de datos meteorológicos. Es bastante confuso escribir pruebas para eso, al menos ya que no tengo demasiada experiencia con TDD.

Perderás clases grandes con múltiples responsabilidades. También es probable que pierda grandes métodos con múltiples responsabilidades. Es posible que pierda alguna capacidad para refactorizar, pero también perderá parte de la necesidad de refactorizar.

Jason Cohen dijo algo como: TDD requiere una cierta organización para su código. Esto podría ser incorrectamente desde el punto de vista arquitectónico; por ejemplo, dado que los métodos privados no se pueden llamar fuera de una clase, debe hacer que los métodos no sean privados para hacerlos comprobable.

Digo que esto indica una abstracción perdida if si el código privado realmente necesita ser probado, probablemente debería estar en una clase separada.

Dave Mann

Tienes Que escribir las aplicaciones de una manera diferente: uno que hace comprobables. Te sorprendería lo difícil que es esto al principio.

Algunas personas encuentran el concepto de pensar en lo que van a escribir antes de escribirlo demasiado duro. Conceptos como la burla también pueden ser difíciles para algunos. TDD en aplicaciones heredadas puede ser muy difícil si no fueron diseñados para pruebas. TDD alrededor de marcos que no son compatibles con TDD también puede ser una lucha.

TDD es una habilidad los desarrolladores junior pueden tener dificultades al principio (principalmente porque no se les ha enseñado a trabajar de esta manera).

En general, aunque los contras se resuelven a medida que la gente se vuelve hábil y termina abstrayendo el código 'maloliente' y tiene un sistema más estable.

Se necesita algún tiempo para entrar en él y algún tiempo para empezar a hacerlo en un proyecto, pero... Siempre me arrepiento de no hacer un enfoque de Prueba cuando encuentro errores tontos que una prueba automatizada podría haber encontrado muy rápido. Además, TDD mejora la calidad del código.

• las pruebas unitarias son más código para escribir, por lo tanto un mayor costo inicial de desarrollo
• es más código para mantener
• se requiere aprendizaje adicional

Buenas respuestas a todos. Añadiría algunas maneras de evitar el lado oscuro del TDD:

• He escrito aplicaciones para hacer su propio auto-test aleatorio. El problema de escribir pruebas específicas es que incluso si escribes muchas de ellas, solo cubren los casos en los que piensas. Los generadores de pruebas aleatorias encuentran problemas en los que no pensabas.

• Todo el concepto de muchas pruebas unitarias implica que tiene componentes que pueden entrar en estados no válidos, como estructuras de datos complejas. Si te quedas lejos de estructuras de datos complejas, hay mucho menos que probar.

• En la medida en que su aplicación lo permita, sea tímido del diseño que se basa en el orden adecuado de las notificaciones, eventos y efectos secundarios. Estos pueden caer o mezclarse fácilmente, por lo que necesitan muchas pruebas.

TDD requiere una cierta organización para su código. Esto puede ser ineficiente o difícil de leer. O incluso arquitectónicamente incorrecto; por ejemplo, dado que los métodos private no se pueden llamar fuera de una clase, tienes que hacer que los métodos no sean privados para hacerlos comprobables, lo cual es simplemente incorrecto.

Cuando el código cambia, también tiene que cambiar las pruebas. Con la refactorización esto puede ser un mucho trabajo extra.

Permítanme añadir que si se aplican los principios BDD a un proyecto TDD, se pueden aliviar algunos de los principales inconvenientes enumerados aquí (confusión, malentendidos, etc.). Si no está familiarizado con BDD, debe leer la introducción de Dan North. Surgió el concepto en respuesta a algunos de los problemas que surgieron de la aplicación de TDD en el lugar de trabajo. La introducción de Dan a BDD se puede encontrar aquí.

Solo hago esta sugerencia porque BDD aborda algunos de estos negativos y actúa como un gap-stop. Querrás considerar esto al recopilar tus comentarios.

Debe asegurarse de que sus pruebas estén siempre actualizadas, el momento en que comienza a ignorar las luces rojas es el momento en que las pruebas carecen de sentido.

También debe asegurarse de que las pruebas sean completas, o en el momento en que aparezca un gran error, el tipo de administración congestionado que finalmente convenció para permitirle pasar tiempo escribiendo más código se quejará.

La persona que enseñó a mi equipo desarrollo ágil no creía en la planificación, solo escribió tanto para el requisito más pequeño.

Su lema era refactor, refactor, refactor. Llegué a entender que refactor significaba "no planificar con antelación".

El tiempo de desarrollo aumenta : Cada método necesita pruebas, y si tiene una aplicación grande con dependencias, necesita preparar y limpiar sus datos para las pruebas.