¿Cuáles son las desventajas de la programación de prueba en primer lugar?

Hay bastantes, pero las ventajas lejos superan las desventajas.

Hay una curva de aprendizaje empinada.

Muchos desarrolladores parecen esperar que puedan ser eficientes con la programación de primera prueba desde el primer día. Desafortunadamente, se necesita mucho tiempo para ganar experiencia y programar a la misma velocidad que antes. No puedes evitarlo.

Para ser más específico, es muy fácil equivocarse. Puede muy fácilmente (con muy buenas intenciones) terminar escribiendo un montón de pruebas que son difíciles de mantener o probar las cosas incorrectas. Es difícil dar ejemplos aquí: este tipo de problemas simplemente requieren experiencia para resolverlos. Debe tener una buena idea de separar las preocupaciones y diseñar para la comprobabilidad. Mi mejor consejo aquí sería hacer una programación en pareja con alguien que sepa muy bien TDD.

Usted hace más codificación por adelantado.

Test-first significa que no puedes omitir las pruebas (lo cual es bueno) y significa que terminarás escribiendo más código por adelantado. Esto significa más tiempo. Una vez más, no puedes evitarlo. Se le recompensa con un código que es más fácil de mantener, extender y, en general, menos errores, pero lleva tiempo.

Puede ser una venta difícil para los gerentes.

Los administradores de software generalmente solo se preocupan por las líneas de tiempo. Si cambias a la programación de prueba primero y de repente te tardas 2 semanas en completar una función en lugar de una, a ellos no les va a gustar. Esta es definitivamente una batalla que vale la pena pelear y muchos gerentes están lo suficientemente iluminados para obtenerla, pero puede ser una venta difícil.

Puede ser una venta difícil para otros desarrolladores.

Ya que hay una curva de aprendizaje empinada, no a todos los desarrolladores les gusta la programación de prueba. De hecho, supongo que a la mayoría de los desarrolladores la mayoría no les gusta al principio. Puedes hacer cosas como la programación en pares para ayudarlos a ponerse al día, pero puede ser una venta difícil.

Al final, las ventajas superan las desventajas, pero no ayuda si simplemente ignora las desventajas. Saber de qué se trata desde el principio le ayuda a negociar algunas de las desventajas, si no todas.

La primera prueba supone que estás escribiendo un código que es:

• verificable en una forma de prueba unitaria
• que lo que está desarrollando tiene un enfoque obvio y no requerirá de prototipos o experimentación extensivos
• que no necesitará refactorizar demasiado o que tiene tiempo para volver a escribir cientos o miles de casos de prueba
• nada está sellado
• todo es modular
• todo es inyectable o simulable
• que su organización otorga un valor suficientemente alto a los defectos bajos para justificar el sumidero de recursos
• que hay algo de beneficio para probar en un nivel de prueba de unidad

Si su proyecto no cumple con esos requisitos, tendrá dificultades. Los promotores de TDD no tienen buenas respuestas a este otro para sugerirle que rediseñe su producto para que se adapte mejor a esas líneas. Hay situaciones en las que eso es imposible o indeseable.

En la práctica, también puede haber un gran problema con las personas que piensan que las pruebas de primera prueba realmente prueban algo sobre la función correcta del programa. En muchos casos esto no es cierto, pero incluso en los casos en que es cierto, dista mucho de ser una imagen completa de la corrección. Las personas ven cientos de pruebas que pasan y asumen que es seguro probar menos, ya que antes de la TDD, de todos modos solo hicieron unos pocos cientos de casos de prueba. En mi experiencia, TDD significa que necesitas tener aún más pruebas de integración, ya que los desarrolladores también tendrán la seguridad falsa y el dolor de cambiar todas las pruebas para hacer un gran redactor puede hacer que los desarrolladores realicen trabajos interesantes.

Ejemplos:

Mi mejor ejemplo personal es cuando escribo un código de seguridad para asp.net. Si están destinados a ejecutarse en un entorno hostil desde la configuración de la máquina, están bien marcados, firmados y sellados, y debido a que se están ejecutando contra los objetos de Dios de IIS, es muy difícil que se burlen de ellos correctamente. Agregue algunas restricciones para el rendimiento y el uso de la memoria y perderá rápidamente la flexibilidad de usar objetos de marcador de posición en las áreas restantes.

Cualquier tipo de microcontrolador u otro código de entorno de bajos recursos puede no ser posible para realizar un diseño de estilo OO real, ya que las abstracciones no se optimizan y tiene bajos límites de recursos. Lo mismo puede decirse de las rutinas de alto rendimiento en muchos casos también.

El mayor inconveniente que he visto no es con la TDD en sí, sino con los profesionales. Toman un enfoque dogmático y fanático donde todo debe ser probado . A veces (muchas veces eso es), eso no es necesario. Además, podría no ser práctico (.ie. Presentar una organización a TDD.)

Un buen ingeniero encuentra compensaciones y aplica el balance correcto de cuándo / dónde / cómo aplicar primero la prueba. Además, si constantemente pasa mucho más tiempo desarrollando pruebas en lugar de código real (por un factor de 2-3 o más), está en problemas.

En otras palabras, sea pragmático y razonable con TDD (o cualquier cosa en el desarrollo de software).

Comencé a hacer TDD a principios de agosto de 2009 y convencí a toda mi compañía para que lo cambiara en septiembre / octubre de 2009. En la actualidad, todo el equipo de desarrollo está completamente convertido, y la confirmación de código no probado en el repositorio se considera una Cosa Mala y se lanza sobre. Ha funcionado muy bien para nosotros, y no puedo imaginar volver a la codificación de vaqueros.

Sin embargo, hay dos problemas que son bastante notables.

El conjunto de pruebas debe mantenerse

Cuando sea serio acerca de TDD, terminará escribiendo lotes de pruebas. Además, se necesita algo de tiempo y experiencia para comprender cuál es la granularidad de las pruebas correctas (la exageración es casi tan mala como hacerla). Estas pruebas también son código , y son susceptibles de bitrot. Esto significa que tiene que mantenerlos como todo lo demás: actualícelos cuando actualice las bibliotecas de las que dependen, refactorice de vez en cuando ... Cuando realice grandes cambios en su código, muchas pruebas quedarán obsoletas de repente o incluso mal. Si tiene suerte, simplemente puede eliminarlos, pero muchas veces terminará extrayendo los bits útiles y adaptándolos a la nueva arquitectura.

Las fugas de abstracciones de prueba de vez en cuando

Estamos usando Django, que tiene un marco de prueba bastante bueno. Sin embargo, a veces hace suposiciones que están ligeramente en desacuerdo con la realidad. Por ejemplo, algún middleware puede romper las pruebas. O, algunas pruebas hacen suposiciones acerca de un backend de almacenamiento en caché. Además, si está utilizando una base de datos "real" (no SQLite3), la preparación de la base de datos para las pruebas llevará mucho tiempo. Claro, puede (y debería) usar SQLite3 y una base de datos en memoria para las pruebas que realiza localmente, pero algunos códigos se comportarán de manera diferente dependiendo de la base de datos que utilice. La configuración de un servidor de integración continua que se ejecuta en una configuración realista es una necesidad.

(Algunas personas te dirán que debes burlarte de todas las cosas, como la base de datos, o que tus pruebas no son "puras", pero eso es solo una ideología. Si cometes errores en tu código de burla (y créeme) will), tu testuite no tendrá ningún valor.)

Todo esto dicho, los problemas que describí comienzan a ser notorios solo cuando está bastante avanzado con TDD ... Cuando recién comienza con TDD (o está trabajando en proyectos más pequeños), la refactorización de prueba no será un problema.

Para mí hay algún problema psicológico profundo con las pruebas cuando trato de aplicarlas extensamente, como en TDD: si están ahí, codifico de forma descuidada porque confío en que las pruebas detecten algún problema. Pero si no hay pruebas para proporcionar una red de seguridad, lo codifico cuidadosamente y el resultado es invariablemente mejor que con las pruebas.

Tal vez sea solo yo. Pero también he leído en alguna parte que los coches con todo tipo de campanas de seguridad y amp; los silbidos tienden a fallar más (porque los conductores saben que las características de seguridad están ahí), así que tal vez esto sea algo para reconocer; TDD puede ser incompatible con algunas personas.

Una situación en la que el test-first realmente se interpone en mi camino es cuando quiero probar rápidamente una idea y ver si puede funcionar antes de escribir una implementación adecuada.

Mi enfoque es normalmente:

1. Implementar algo que se ejecuta (prueba de concepto).
2. Si funciona, consolide agregando pruebas, mejorando el diseño, refactorizando.

A veces no llego al paso 2.

En este caso, el uso de TDD ha resultado tener más desventajas que ventajas para mí:

• Escribiendo pruebas durante la implementación de la prueba de concepto solo me ralentiza e interrumpe mi flujo de pensamientos: quiero entender una idea y no quiero perder el tiempo probando los detalles de mi primera implementación aproximada.
• Puede llevar más tiempo averiguar si mi idea vale algo o no.
• Si resulta que la idea fue inútil, tengo que desechar mi código y mis pruebas de unidad bien escritas.

Entonces, cuando tengo que explorar algunas ideas nuevas, no uso TDD y solo introduzco pruebas unitarias cuando tengo la sensación de que el nuevo código está llegando a alguna parte.

Los beneficios de TDD son que te obliga a proteger tu código contra personas que no lo entienden. Sí, esto a menudo se incluye a ti mismo. Pero, ¿qué pasa cuando no vale la pena guardar el código? ¡Hay un montón de código que ni siquiera debería estar allí en primer lugar! Entonces, el problema con TDD es cuando se trata de desarrolladores que escriben código incorrecto. Es probable que TDD no los ayude a escribir un buen código, es mucho más probable que ellos también escriban pruebas horribles. Así, en su caso, TDD solo añadirá al desorden; Las pruebas mal escritas y / o redundantes no son más divertidas que otras formas de código incorrecto.

Desventajas o costos de TDD

Nota: Existe una variedad de diferentes tipos de TDD. Independientemente de la unidad, BDD, ATDD u otras variantes, muchas de las dificultades permanecen

Efectos secundarios

Si se trata de burlas, arreglos o pruebas funcionales, las dependencias de estados o sistemas externos son a menudo la fuente de la mayor complejidad en las pruebas, la confusión en la forma de realizar las pruebas y el mayor riesgo de hacerlo mal. Algunos problemas que he visto:

• Burlándose: olvídate de hacer valer el orden de las llamadas
• Simulacros: el simulacro no coincide con una llamada o respuesta real
• Fixture: la prueba se basa en datos poco realistas, enmascarando otros problemas
• Accesorio: prueba un estado imposible en producción
• Funcional: falso se rompe la construcción debido a que el sistema dependiente no está disponible temporalmente
• Funcional: la velocidad de la prueba es muy lenta

Tendrá que cambiar su enfoque de codificación, para algunos será un cambio drástico.

Diferentes personas codifican de maneras muy diferentes. En TDD, debe comenzar con una prueba que afirma un comportamiento específico y luego implementarlo para que la prueba pase. He visto y era un programador cuya programación no era propicia para TDD. Me tomó cerca de 2 meses cuando comencé a acostumbrarme a cambiar mi enfoque de desarrollo.

Lleva tiempo entender lo que te importa de las pruebas y lo que no te interesan de las pruebas.

Cada equipo debe tomar una decisión explícita sobre dónde quiere dibujar la línea en las pruebas. Qué cosas valoran que quieren que se prueben y qué no. A menudo es un proceso doloroso que aprende a escribir buenas pruebas, y lo que realmente te importa de las pruebas. Mientras tanto, el código continuará en un estado de flujo hasta que haya coherencia tanto en el estilo como en el enfoque.

Prueba de unidad específica: refactores grandes

Un refactor grande o fundamental de un código base significativo con decenas de miles de pruebas unitarias generará un costo enorme para actualizar todas las pruebas. Esto a menudo se manifestará en un rechazo contra hacer un refactor, incluso si es lo correcto, simplemente porque el costo asociado con hacerlo.

Mi analogía es las barreras en una pista Scalextric. Si te los pones, te volverás mucho menos cauteloso.

Las personas también tienen un poco de espacio para sus pruebas, porque funcionan bien, creen que el código está completamente probado, mientras que es solo el comienzo del proceso de prueba.

En mi opinión, TDD es un trampolín para BDD. Una serie de pruebas que se ejecutan realmente no ayuda a los desarrolladores sin saber qué hacen las pruebas. Con BDD, la salida de la prueba está en inglés, lo que documenta la prueba y, por lo tanto, aumenta la comprensión del sistema.