¿Debo refactorizar mis pruebas unitarias cuando extraigo una clase del Sistema a prueba?

13

Escribí esta clase que hace algunas cosas (tal vez esto sea una violación del Principio de Responsabilidad Única). Ahora me doy cuenta de que alguna otra parte del proyecto necesita una pieza de esa lógica y la forma en que lo expondré es extraer una clase de mi sistema bajo prueba original.

Anticipo poder hacer esto sin tener que cambiar ningún código de prueba, pero cuando termine, podría argumentar que la prueba ya no es una prueba de unidad . Estará probando la clase original y la clase que he extraído. En otras palabras, tendré un caso de prueba, pero dos sistemas bajo prueba.

¿Se supone que debo refactorizar mi código de prueba después de que termine? IE: ¿Crear un ExtractedClassTest y mover todas las pruebas relevantes de OriginalClassTest en él? Parece que podría ser un poco arriesgado: es posible que pierda algo de cobertura en el proceso, que no sea tan simple como mover una prueba y que termine de reescribir un código de prueba que sé que solía funcionar pero que ya no funciona. etc.

Por otra parte, si dejo el OriginalClassTest como está, puedo ver que esto es un problema de mantenimiento de prueba. Será un poco confuso encontrar dónde están las pruebas ExtractedClass. Tu primera impresión será que no existe. Con el tiempo, con muchas refactorizaciones de código de producción, esto podría convertirse en un problema grave.

Soy nuevo en TDD, así que me gustaría el consejo de un experto. Gracias!

    
pregunta Daniel Kaplan 09.02.2013 - 01:10

2 respuestas

7

Después de ver esta charla increíble "Ian Cooper: TDD, ¿dónde salió todo mal?", no voy a estar de acuerdo con @ pdr Creo que solo deberías guardar las pruebas originales. Su capacidad para refactorizar su sistema bajo prueba sin romper, escribir o cambiar cualquier prueba es el propósito principal de escribir pruebas en primer lugar.

Si tuviera que probar la clase extraída, estaría probando la implementación en lugar del comportamiento. Como resultado, mi código sería más difícil de refactorizar en el futuro: estas nuevas pruebas probablemente fallarían incluso si el comportamiento aún funcionara.

    
respondido por el Daniel Kaplan 26.03.2014 - 18:02
6

Durante la duración del desarrollo, tener ambos. Mantenga las pruebas anteriores como garantía de que no ha roto nada, escriba nuevas pruebas (desde cero) para ayudarlo a diseñar las clases como deberían ser.

Al final, ejecute y elimine todo lo que haya desaparecido en las pruebas anteriores. Tenga cuidado en este análisis; No elimines algo porque piensas que debería estar desactualizado. Demuestre usted mismo (o alguien más, o un pato de goma) por qué ya no es necesario. Rompa la prueba y asegúrese de que otra prueba rompe con ella.

Todo lo que quede en las pruebas anteriores debe tomarse caso por caso, pero sobre todo deben reescribirse en la nueva estructura.

Porque tienes razón, no quieres quedarte con una pesadilla de mantenimiento. Pero no desea menos cobertura de ruta que la que tenía anteriormente.

    
respondido por el pdr 09.02.2013 - 01:17

Lea otras preguntas en las etiquetas