¿Cómo hago TDD cuando se debe cambiar el comportamiento esperado?

7

He estado haciendo TDD con un proyecto en el que estoy trabajando y tengo un gran número de pruebas. Tengo bastantes pruebas automatizadas en torno a las restricciones impuestas en el código, asegurándome de que no se permitan las cosas que no deberían permitirse. Ahora me han dicho que debido a los cambios en nuestro modelo de licencias, es necesario eliminar algunas de esas restricciones.

Desde que hice todo el proyecto con TDD, no estoy seguro de cómo hacer un cambio como este también con la mentalidad de TDD.

Entonces, mi pregunta es: ¿Realizo los cambios en el back-end y veo qué pruebas se rompen, o trato de encontrar las pruebas que imponen el comportamiento y las cambio primero?

Mi preocupación es que si hay operaciones A, B, C y D donde se realiza una verificación para rechazar el comportamiento, y tengo pruebas equivalentes TestA, TestB, TestC y TestD (posiblemente en diferentes lugares) sin importar cuál La mitad me cambio primero, es posible que pierda uno o dos puntos y termine con un comportamiento incorrecto, pero aún así me hayan superado todas las pruebas (por ejemplo, ¿qué pasa si me olvido de TestD?)

    
pregunta Shawn D. 28.10.2011 - 00:41

4 respuestas

12

Habiendo hecho todo el proyecto con TDD, te aconsejaría que siguieras con él. Muchos requisitos están cambiando, pero tómelos uno por uno. Para un nuevo requisito, escriba una prueba para ello o encuentre la prueba existente que ahora debería tener resultados diferentes. Cámbielo para que se corresponda con el nuevo requisito y observe que se vuelve rojo. Ahora hazlo pasar. Cuando lo haga pasar, puede encontrar otra prueba (o pruebas), porque esa prueba dependía del comportamiento anterior. Esta bien. Revise la prueba de ruptura y asegúrese de que no haya roto realmente el comportamiento (si lo ha hecho, deshaga el cambio). Actualice la prueba de ruptura para que se corresponda con el nuevo comportamiento deseado y observe que se vuelve verde. Repita hasta que termine.

    
respondido por el Carl Manaster 28.10.2011 - 00:54
5

Lo ideal es encontrar las pruebas que imponen el comportamiento y cambiarlas primero. De esta manera puede ver que la prueba falla antes de hacerla nuevamente, lo que es un TDD perfecto.

Si pierdes uno, que así sea. El pragmatismo por lo general se activaría y usted simplemente arregla la prueba.

Si estaba siendo realmente pedante, debería poder volver a cambiar el código, cambiar la prueba, ver cómo fallan todos y luego corregirlo nuevamente. Soy bastante estricto conmigo mismo con respecto a TDD e incluso no soy tan pedante. Simplemente no creo que ese paso ofrezca mucho.

    
respondido por el pdr 28.10.2011 - 00:55
0

La forma habitual de lidiar con esto es introducir una bandera y cambiar el comportamiento de los códigos de prueba y producción según la bandera. Por ejemplo, si introduce compras autoservicios de fraudes de vainilla, entonces el código de prueba verificará el indicador HAVE_AUTO_FRAPPE y assertTrue () o assertFalse () dependiendo de ello. Esto tiene la ventaja de que tiene que realizar el cambio en su suite de prueba y en el código de producción solo una vez. Cuando el cambio surta efecto, simplemente volteas el bit y nada más. (Por supuesto, puede eliminar todo el mecanismo más adelante si definitivamente no va a volver a cambiar, por ejemplo, al refactorizar para mayor claridad, pero no tiene que hacerlo).

    
respondido por el Kilian Foth 28.10.2011 - 09:01
0

Con TDD, por definición, necesitaría cambiar las pruebas para reflejar los nuevos comportamientos, y luego modificar el código hasta que todas las pruebas pasen. Sin embargo, dependiendo del tamaño de su base de código y la cantidad de tiempo que se le ha asignado a usted (y a su equipo) para completar esta transición, es posible que no haya tiempo suficiente para hacerlo de esa manera. Es posible que tenga que seleccionar algunas secciones clave, actualizar las pruebas y luego el código, e impulsar los cambios gradualmente.

    
respondido por el JW8 28.10.2011 - 20:33

Lea otras preguntas en las etiquetas