¿Valen la pena las pruebas unitarias o el desarrollo basado en pruebas?

Respuesta corta: absolutamente positiva.

Respuesta larga: las pruebas unitarias son una de las prácticas más importantes que trato de influir en mi lugar de trabajo (banco grande, comercio de divisas). Sí, son trabajo extra, pero es un trabajo que se paga una y otra vez. Las pruebas unitarias automatizadas no solo lo ayudan a ejecutar el código que está escribiendo y, por supuesto, verifican sus expectativas, sino que también actúan como una especie de perro guardián para los cambios futuros que usted o alguien más puedan hacer. Se producirá una rotura de prueba cuando alguien cambie el código de manera no deseada. Creo que el valor relativo de las pruebas unitarias disminuye en correlación con el nivel de cambio esperado y el crecimiento en una base de código, pero la verificación inicial de lo que hace el código hace que valga la pena incluso cuando el cambio esperado es bajo. El valor unitario de la prueba también depende del costo de los defectos. Si el costo (donde el costo es la pérdida de tiempo / dinero / reputación / esfuerzo futuro) de un defecto es cero, entonces el valor relativo de una prueba también es cero; sin embargo, esto casi nunca es el caso en un entorno comercial.

Por lo general, ya no contratamos a personas que no realizan pruebas de unidad de forma rutinaria como parte de su trabajo; es algo que esperamos, como aparecer todos los días. No he visto un análisis de costo beneficio puro de las pruebas unitarias (alguien puede dirigirme a uno), pero puedo decir por experiencia que, en un entorno comercial, vale la pena probar que el código funciona en un sistema importante. . También me permite dormir mejor por la noche sabiendo que el código que he escrito funciona correctamente (a un cierto nivel), y si cambia, una compilación rota alertará sobre cualquier efecto secundario inesperado.

El desarrollo guiado por pruebas, en mi opinión no es un enfoque de prueba. En realidad, es un enfoque / práctica de diseño en el que la salida es el sistema operativo y un conjunto de pruebas unitarias. Soy menos religioso sobre esta práctica, ya que es una habilidad que es bastante difícil de desarrollar y perfeccionar. Personalmente, si estoy creando un sistema y no tengo una idea clara de cómo funcionará, emplearé TDD para ayudarme a encontrar mi camino en la oscuridad. Sin embargo, si estoy aplicando un patrón / solución existente, normalmente no lo haré.

Si no tiene pruebas matemáticas de que tiene sentido escribir pruebas unitarias, lo aliento a que lo pruebe durante un período prolongado y experimente los beneficios usted mismo.

Los errores detectados anteriormente son menos costosos de reparar que los detectados posteriormente. TDD le ayuda a verificar la corrección de su sistema. Usted invierte un poco más por adelantado, pero recupérelo más tarde. El gráfico es un poco exagerado, pero muestra bien la idea.

Fuente de imagen

  

Parece que escribir pruebas es un trabajo extra, le da a las personas una muleta cuando escriben el código real y es posible que no sea muy efectivo con mucha frecuencia.

La prueba de la unidad tiene valor como muleta. Es compatible con sus esfuerzos de desarrollo, lo que le permite cambiar su implementación sin temor a que su aplicación deje de funcionar según sea necesario. Las pruebas unitarias también son mucho más que una muleta, ya que le brindan una herramienta con la que puede validar que su implementación cumple con los requisitos.

Todas las pruebas, ya sean pruebas unitarias, pruebas de aceptación, pruebas de integración, etc., son tan efectivas como las personas que las usan. Si aborda su trabajo de forma descuidada, sus pruebas serán descuidadas y su implementación tendrá problemas. ¿Entonces, para qué molestarse? Se molesta en las pruebas porque necesita probarse a sí mismo y a sus clientes que su software funciona y no tiene ningún problema que pueda impedir que se use el software. Sí, las pruebas son definitivamente un trabajo extra, pero la forma en que las pruebas determinarán cuánto esfuerzo necesitarás poner para corregir errores después de la publicación y cuánto esfuerzo requerirá cambiar y mantener tu código.

  

Entiendo cómo funcionan las pruebas unitarias y cómo escribirlas, pero ¿puede alguien afirmar que realmente es una buena idea y que vale la pena el esfuerzo y el tiempo?

TDD, y en realidad, cualquier método que requiera que usted escriba pruebas antes de codificar adopta el enfoque que realizó en un esfuerzo inicial como pago inicial de deuda técnica futura. A medida que trabaje en el proyecto, todo lo que se pierda o no se implemente bien incurrirá en más deuda técnica en forma de una mayor dificultad de mantenimiento, que afecta directamente los costos futuros y los requisitos de recursos. Las pruebas por adelantado aseguran que no solo haya hecho un esfuerzo para abordar futuras deudas técnicas, sino que también garantiza que codifique sus requisitos de tal manera que puedan verificarse simplemente ejecutando su código. La primera prueba también le brinda la oportunidad de validar su comprensión del dominio del problema antes de comprometerse a resolver el problema en el código, y valida sus esfuerzos de implementación.

Realmente se trata de intentar maximizar el valor comercial de su código. El código que en gran medida no se ha probado y es difícil de mantener es generalmente barato y rápido de crear, y muy costoso de mantener durante la vida útil del producto después del lanzamiento. El código que se ha probado exhaustivamente en el nivel de la unidad es generalmente más costoso de crear, pero su costo es relativamente pequeño durante la vida útil del producto después del lanzamiento.

  

Además, ¿hay algo que haga que TDD sea especialmente bueno para SCRUM?

TDD no es específicamente bueno para ninguna metodología en particular. Es simplemente una herramienta. Una práctica que puede integrar en sus procesos de desarrollo para ayudarlo a lograr sus resultados específicos. Entonces, para responder a su pregunta, TDD complementa su método, ya sea SCRUM o cualquier otro enfoque.

  

¿Valen la pena las pruebas unitarias o el desarrollo basado en pruebas?

Sí, lo hace . El tío Bob (Robert C Martin) contó en una presentación;

  

Para que un desarrollador pruebe que su código funciona mejor para escribir una prueba y aprobarla que gritar, cantar o bailar sobre ella.

Y como no va a eliminar la prueba, siempre que la prueba sea una aprobación, está seguro de que la funcionalidad funciona : los problemas de regresión se solucionaron.

Hay muchas cosas escritas en él,

1. Eres responsable de hacer que esa característica funcione. Escribe una prueba. Solo hazlo.
2. Cuándo reemplazar las pruebas unitarias con la prueba de integración

  

¿Están relacionados SCRUM, Unit testing y TDD?

En breve, cuando seas un maestro en Unit testing estarás cerca de TDD . SCRUM no tiene nada que ver con esto, pero como dicen, las grandes cosas se mezclan bien, estas técnicas de desarrollo de un software se convierten en una excelente pila , si no lo has hecho Lo probé pero inténtalo.

  

¿Hay algo que hace que TDD sea especialmente bueno para SCRUM?

Como dije anteriormente, hacen una buena combinación ; Si le agrega algunas pruebas de automatización , entonces es más especial .

La gente piensa que es un esfuerzo extra porque es una actividad inicial. Lo que pierdes en el tiempo ahora lo recuperas más tarde.

Mis razones para las pruebas unitarias también incluyen:

Te da un objetivo: no puedes escribir una prueba si no sabes qué debería hacer el software. Esto ayuda a eliminar los problemas en las especificaciones antes que después.

Te da una sensación de progreso.

Le advierte si un cambio de código altera la salida de otras áreas de código. Eso facilita la refactorización.

Proporciona una capa adicional de documentación (especialmente si comenta sus pruebas correctamente).

Alienta todo tipo de buenas prácticas. Debido a que las pruebas deben ejecutarse con rapidez, lo alienta a escribir código que está desacoplado y que admite la burla. Todo esto ayuda a refactorizar.

Hay otros también cubiertos en otras publicaciones en este hilo. Vale la pena.

  

¿Valen la pena las pruebas unitarias o el desarrollo basado en pruebas?

Definitivamente sí (ver las otras respuestas)

  

[¿Es] realmente una buena idea y vale la pena el esfuerzo y el tiempo?

• Sí si comienza algo nuevo (agregue un módulo nuevo o una aplicación completamente nueva)
• No si ya existe una gran cantidad de código existente que no se desarrolló mediante pruebas y que debe extenderse (legado).

En mi opinión, el desarrollo guiado por pruebas es más efectivo si escribe las pruebas unitarias antes del código real. De esta manera, el código que cumple con las pruebas se separa claramente con un mínimo de referencias externas que se pueden probar fácilmente.

Si el código ya existe sin las pruebas de unidad allí, por lo general es mucho trabajo adicional escribir las pruebas de unidad luego porque el código no se escribió para una prueba fácil.

Si haces TDD, el código se puede probar fácilmente.

Déjame abordar esto desde el otro lado. ¿Qué sucede cuando desarrollas una aplicación no trivial sin pruebas unitarias? Si tiene un buen departamento de control de calidad, una de las primeras cosas que sucederá es que encontrará una gran cantidad de problemas informados. Porque porque no probaste lo que hiciste y asumiste que funcionaría y porque no prestaste mucha atención a los requisitos y tu aplicación no los cumple. Vaya al tablero de dibujo para volver a escribir y corregir. Ahora ha realizado las correcciones y encuentra un nuevo conjunto de problemas porque no tenía forma de verificar que sus correcciones no afectaran a nada más antes de pasar al control de calidad. La fecha límite de Oops ha llegado y se ha ido y la administración está molesta.

La situación es peor si no tiene un buen departamento de control de calidad porque los usuarios encontrarán los errores y no solo harán que su jefe se sienta infeliz, sino que también harán que el entorno de producción caiga de rodillas y cientos o incluso miles de personas. estará parado mientras arregla los errores que las pruebas de unidad habrían evitado. Esta NO es una buena elección de carrera.

Ahora supongamos que este enfoque de vaquero continúa durante años. Ahora, todos los cambios, incluso los triviales, parecen generar nuevos problemas insospechados. No solo eso, sino muchas de las cosas que le gustaría hacer para que la aplicación funcione mejor, no puede hacerlo porque son demasiado riesgosas o demasiado caras, o ambas cosas. Así que colocas parches en los parches, lo que hace que el sistema sea cada vez más complicado, con más errores y más difícil de usar.

Los usuarios comienzan a cuestionar sus estimaciones de tiempo porque siguen haciéndose cada vez más grandes y es difícil explicarles que el sistema se ha convertido en un desastre tan complicado, que es difícil encontrar dónde realizar los cambios y aún más difícil asegurarse no rompen otra cosa

Trabajé en un lugar como este donde, después de diez años de desarrollo, prácticamente nada de lo que queríamos hacer para solucionar los problemas reales se podía hacer porque no sabíamos cuál de los cientos de aplicaciones cliente personalizadas se rompería. Los desarrolladores iniciales fueron en gran medida las "pruebas unitarias, no necesitamos pruebas de unidades apestosas" del tipo de desarrolladores. Todos los que los siguieron sufrieron gracias a su falta de visión.

Sin pruebas unitarias, el software tiene más problemas y lleva más tiempo desarrollar y mantener inicialmente. ¿Por qué demonios no querrías hacer pruebas unitarias? El tiempo que dedique a escribir la prueba será mucho menor que el tiempo que dedicaría a solucionar los problemas que debería haber encontrado anteriormente (cuanto más pronto se detectó el error, menos tiempo demorará la reparación) y los problemas que habría evitado por completo al escribir las pruebas. primero, lo que permite comprender mejor los requisitos antes de comenzar la codificación.

Todo el código que escriba debe probarse en algún momento. No desea escribir todo de una vez y luego presionar el botón de compilación y cruzar los dedos. Usted escribe y compila bloques pequeños y envía información cuidadosamente elaborada a su código para verificar que hace lo que usted cree que hace. Luego, generalmente elimina su aparato de prueba ad-hoc y pasa al siguiente componente.

Con las pruebas unitarias, simplifica este proceso y te da una excusa para mantener tus pruebas alrededor. De esa manera, si realiza cambios que rompen las cosas que probó en el pasado, puede capturar esa regresión explícitamente en lugar de permitir que afecte a otras partes de su código. Hay un valor real en eso.

En cuanto al enfoque refactor rojo-verde para TDD, lo encuentro un poco tedioso. Pero a cada uno lo suyo.

La mayoría de las veces me parece que los desarrolladores son resistentes a la idea de escribir pruebas. No es tanto que argumenten que las pruebas no tienen ningún valor, sino que son simplemente un medio para descubrir cómo resolver un problema en particular. Por lo general, este problema cambia según el contexto. Una vez hecho esto, las pruebas no tienen ningún propósito y podrían eliminarse. Aquí hay una muestra de los contextos que mis colegas han dado en el pasado sobre cómo decidir cuándo escribir una prueba y encontrará que la única respuesta posible según ellos nunca es:

• el problema en cuestión debe ser un ejemplo de libro de texto para TDD, como una pila o una calculadora
• el código trivial no se debe probar (invalida el argumento anterior)
• el código crítico o difícil debe probarse exhaustivamente (implícito en el argumento anterior)
• las pruebas no deben estar acopladas a la implementación para permitir la refactorización (invalida el argumento anterior)
• no es necesario realizar pruebas de efectos secundarios, como llamar a un servicio de terceros con una carga útil específica (por lo tanto, no hay pruebas de caja negra)

En realidad, hay un tipo de prueba que, en general, se acepta y que, en última instancia, creo que es inútil. A saber, pruebas basadas en GUI, como el uso de selenio, webdriver, watir o arquillian. Así es como obtenemos los ciclos de compilación de 7 horas en lugar de los ciclos de compilación de 5 minutos en mis proyectos TDD.

Estos mismos desarrolladores generalmente se quejan con todos los demás de lo malo que es el código y de lo incompetentes que deben haber sido los desarrolladores anteriores. A ellos también les resulta extremadamente importante hacer un diseño adecuado utilizando una pizarra, MS office o un wiki y cuidamos mucho de que este diseño se mantenga actualizado.

Esto último es lo que realmente me hizo darme cuenta de que tales desarrolladores son fraudes. Todos sabemos que cualquier documento de diseño que no sea una prueba de unidad quedará desactualizado y no se mantendrá actualizado debido al costo total de mantenimiento para hacerlo. De hecho, he intentado y he tratado de encontrar un buen medio para expresar ideas de diseño en formato MS office que fuera útil y legible tanto antes como después del hecho de escribir el código. Fallé en todos los casos y, aunque hay personas que logran producir un documento de MS Office que parece bastante, tampoco los encontré útiles.

Entonces, tienes una opción. Puede realizar el diseño y la documentación practicando TDD, que es el único método conocido y comprobado para producir dicha documentación en base a mis 10 años de experiencia en desarrollo. O puedes entrar en política.