En el desarrollo guiado por pruebas, ¿existen buenas razones para no escribir varias pruebas fallidas y solo para hacerlas pasar?

7

Las tres reglas de desarrollo impulsadas por pruebas del tío Bob establecen lo siguiente:

  
  1. No se le permite escribir ningún código de producción a menos que sea para hacer una prueba de prueba fallida.
  2.   
  3. No se le permite escribir más de una prueba de unidad de lo que es suficiente para fallar; y las fallas de compilación son fallas.
  4.   
  5. No se le permite escribir más código de producción del que sea suficiente para pasar la única prueba de unidad que falla.
  6.   

Algunas personas argumentan que la segunda regla implica que solo debe agregar una prueba que falla (un ejemplo de un comportamiento aislado). Pero otros argumentan que también podría significar que puede agregar varias pruebas fallidas en un conjunto de pruebas, siempre y cuando deje de trabajar en cada prueba por separado tan pronto como falle.

Me gustaría saber qué ventajas obtiene al limitarse a escribir solo una nueva prueba fallida y luego dejar de escribir el código de la prueba hasta que la haya aprobado.

    
pregunta aef 11.04.2016 - 21:14

3 respuestas

9

Cuando escribe dos pruebas a la vez y comienza a implementar el código para realizar la primera prueba, no puede ejecutar el conjunto de pruebas completo y obtener un resultado "verde", ya que la segunda prueba seguirá fallando. Puede ver el resultado detallado de su marco de prueba de unidad y verificar visualmente que la prueba falló exactamente lo que esperaba, por supuesto, pero que puede volverse engorroso y propenso a errores, especialmente cuando su número de pruebas de unidad comienza a crecer . Y si tiene, por ejemplo, algo así como un sistema CI instalado con una regla de que no se deben registrar pruebas fallidas, porque las pruebas fallidas cuentan como construcciones rotas, esto significa que no puede verificar su código hasta que haya implementado suficiente código para hacer todas las pruebas pasan.

Tenga en cuenta que este es un modelo idealizado; está diseñado para capacitarse para trabajar en los pasos más pequeños posibles, brindándole un programa compilable y totalmente probado cada pocos minutos. La idea es que cuanto más pequeños sean tus pasos de un "estado totalmente operativo" a otro, mejor podrás controlar el proceso.

Por supuesto, cuando realice la "programación del mundo real", si lo prefiere, puede elegir el orden de implementación de las pruebas y el código de producción que desee, cuando crea que los pasos más grandes se ajustarán mejor a sus necesidades. Sin embargo, cuando trabaje de esta manera, puede ser una buena idea desactivar o comentar explícitamente cualquier prueba que haya escrito de antemano hasta que comience a trabajar en la parte relacionada del código de producción.

    
respondido por el Doc Brown 11.04.2016 - 21:53
6

La razón para quedarse con una prueba de unidad que falla a la vez es el enfoque. Cuando tiene esa única prueba de unidad que falla, sabe exactamente en qué trabajar; sabes en qué parte del código pensar; Sabes qué problema estás resolviendo de inmediato. Si te permites escribir más pruebas mientras trabajas para resolver un problema, muy pronto estarás resolviendo dos, o cinco o diez, y con esa falta de enfoque, realmente no estás resolviendo nada.

Por supuesto, a medida que descubra la necesidad adicional de las pruebas, incluso cuando la prueba sigue fallando: anótela. Revise sus notas después de obtener la prueba para aprobar y elija una para trabajar mientras aún esté fresca en su mente. Pero si escribe esa prueba adicional de manera prematura, se aleja de todo verde y no quiere estar muy lejos de ese estado.

Además, si te sientes en la necesidad de pruebas adicionales, deja que esa sensación te guíe para escribir pruebas más pequeñas para empezar.

Este es el dogma básico de TDD; en la práctica, muchos de nosotros lo violamos ocasionalmente y escribimos esa segunda prueba fallida. Pero cuando estamos en nuestro mejor momento, es solo una prueba fallida a la vez, y el enfoque es la razón.

    
respondido por el Carl Manaster 11.04.2016 - 21:55
0

Haciendo sus propios proyectos, puede escribir tantas pruebas como desee, pero mi experiencia en negocios reales es que las pruebas o refactorizaciones son requisitos no funcionales solo en su opinión y su cliente tiene que pagar por el Tiempo que necesitas para escribir tus pruebas. Si bien una prueba es parte inherente de cada problema en su proyecto, no debe ser exagerada.

¿Es la misma discusión acerca de cuántas pruebas unitarias garantizan la calidad de mi software en comparación con una buena prueba de integración? Piense en las palabras de Uncle-Bob que prueban una clase modelo:

  • (prueba) "debería devolver un mensaje": model = new NewsModel()
  • (la prueba falla) NewsModel no está definido
  • (prueba de correcciones implícitas) class NewsModel {}
  • (prueba) model.getMessage()
  • (failes de prueba) NewsModel::getMessage no está definido
  • (prueba de correcciones implícitas) public getMessage() {}
  • ...

No estoy de acuerdo con ese estricto red / green / refactor, ya que una buena prueba de integración debería revelar un mal comportamiento y no creo que sea la intención del Tío Bob el que escriba pruebas modelo de esa manera. El mensaje es solo que no debe perderse en horas de pruebas, pero escriba buenas pruebas y al menos no haga doble prueba de comportamiento.

Si puede formar cada pequeña parte de los requisitos de su cliente en una prueba, enviará un software excepcional, si su implementación hace que las pruebas se aprueben. Lo mismo ocurre con los errores: escriba una prueba que la reproduzca (rojo), luego corríjala (verde) y al menos refactoricela.

Y ahora de nuevo a tu pregunta: Si solo falla una prueba, aísla ese mal comportamiento al tiempo que garantiza que todos los demás componentes se comporten correctamente. Si está intentando solucionarlo y luego fallan dos pruebas, es posible que vaya en una dirección incorrecta.

    
respondido por el Aitch 12.04.2016 - 00:35

Lea otras preguntas en las etiquetas