¿Debo escribir una prueba para demostrar que eliminar código corrige un error?

Ocasionalmente me encontraré con la situación en la que corregir un error requiere que elimine una sección de código. El purista de TDD (supongo) recomendaría escribir una prueba fallida, eliminar el código y luego ver pasar la prueba.

Ahora, parece realmente extraño tener una prueba que afirme que se eliminó algún código. Claro, supongo que garantizaría que nadie cavara en el control de la fuente y volviera a poner ese código, pero ¿vale la pena? Si vale la pena, ciertamente parece menos valioso que escribir una prueba de código que se ha agregado , ¿verdad?

unit-testing tdd bug

— jhewlett
fuente

Creo que cualquier prueba de regresión es útil, independientemente de cómo se solucionó el error

— Ismail Badawi

La prueba se realiza con afirmar el código fue eliminado - la prueba afirma el error se corrige ...

— user253751

Lo estás mirando de la manera incorrecta. La prueba no afirma que se eliminó el código. La prueba hace afirmar una cierta funcionalidad.

La prueba no se preocupa por la cantidad de código requerida para que pase, ni se da cuenta de que ha eliminado algún código. El valor de tener una prueba de este tipo es el mismo que cualquier otra prueba que cree debido a un error: tiene confianza en la ausencia del error cuando pasa la prueba y la integración de la prueba en el proceso de compilación le garantiza que el error lo más probable es que no se reintroduzca.

Otra forma de verlo desde una perspectiva TDD es la siguiente: cuando sabe que eliminar el código corrige el error y luego se pregunta si debe escribir una prueba, ya lo hizo mal. Una vez que comience a trabajar en el error, primero debe escribir la prueba que garantiza la presencia del error al fallar. Solo después corrige el error real, que puede requerir la eliminación del código o no, y hace que la prueba pase. La pregunta que haces ni siquiera surge de esa manera.

— Franco
fuente

+1, pero puedo imaginar la siguiente situación: el código eliminado contenía una funcionalidad absurda que alguien agregó que no entendió el dominio del problema correctamente. Ahora, durante una revisión de código, otro desarrollador ve que toda la parte no tiene sentido y que el código se eliminará. Tener muchas pruebas para ese comportamiento sin sentido puede inflar su conjunto de pruebas.

— Doc Brown

Claramente, la funcionalidad eliminada maneja mal algunas entradas / salidas. Claramente, alguien en el futuro podría malinterpretar el problema de la misma manera. Si temes la hinchazón de la suite de prueba, no creo que TDD sea para ti. ¿Qué es la hinchazón de prueba de todos modos?

— Dorus

@DocBrown: Si están haciendo TDD, entonces debe haber alguna prueba que requiera esa funcionalidad absurda, de lo contrario, ¡ni siquiera se les habría permitido escribir ese código en primer lugar! Recuerde, solo puede escribir la cantidad mínima absoluta de código para aprobar la prueba. Si no existe tal prueba, entonces el código nunca debería haberse escrito en primer lugar y simplemente se puede eliminar. Si no es una prueba de que las fuerzas que el comportamiento absurdo, entonces esa prueba deben ser eliminados, y ahora nos encontramos en el mismo caso que he descrito antes: la prueba se ha ido, borrar el código.

— Jörg W Mittag

En ambos casos, nunca agrega ninguna prueba al conjunto de pruebas, y en el segundo caso, incluso elimina una. Sin embargo, si resulta que la prueba realmente tiene sentido, bueno, entonces la funcionalidad no era tan absurda después de todo.

— Jörg W Mittag