¿Cómo funcionan el desarrollo basado en pruebas y el principio abierto/cerrado?

Question

He estado leyendo sobre pruebas unitarias, TDD y los principios SÓLIDOS, y necesito algunas aclaraciones. Según entiendo, si se sigue el principio de abierto/cerrado, las pruebas unitarias podrían resultar innecesarias debido a que el código está cerrado a modificaciones, por lo que no es necesario volver a realizar la prueba si el código se ha aislado y desacoplado correctamente. El beneficio a largo plazo del costo inicial agregado de las pruebas unitarias se pierde si una vez que el código pasa las pruebas de unidades relacionadas, no cambiará. El código siempre pasará porque nunca cambiará, ¿verdad? Las clases heredadas deberán probarse, pero una vez que pasen las pruebas relacionadas, también estarán cerradas a la modificación y no necesitarán volver a someterse a prueba. The Wikipedia article on OCP refuerza esta línea de pensamiento en el primer párrafo, (me doy cuenta de que eso no lo convierte en ley).
La mejor explicación que he encontrado para OCP y TDD viviendo en armonía is here, aunque parece que Arnon dice que OCP complementa TDD en que se desaconseja a los desarrolladores modificar el código fuente porque los métodos de prueba existentes pueden volverse complejos cuando se modifican para probar nueva funcionalidad.
¿Eso es todo lo que hay que hacer? Ten en cuenta que no estoy buscando una discusión, soy nuevo en esto y estoy buscando una aclaración de aquellos con más experiencia con el tema que yo.

Answer 1

Incluso si aceptaras que una vez que el software funciona y no cambia, no es necesario que lo pruebe (lo que yo no), aún necesita mostrar que un componente funciona en primer lugar. Yo diría que una de las mejores maneras de hacerlo es una prueba de unidad (es).

Además, en términos prácticos, una vez que tiene la prueba, cuesta muy poco ejecutarla. Entonces, incluso si los componentes no cambian, no está perdiendo mucho ejecutando continuamente las pruebas. Además, algunas veces los cambios de diseño necesitan volver atrás y volver a hacer algunos componentes. Tener pruebas unitarias definitivamente ayuda en este caso ...

Recuerde, uno de los resultados de tener un conjunto de pruebas es que promueve el mantenimiento mostrando cuando algo cambios. Entonces, incluso si su equipo sigue a la O en SOLIDO, eso no significa que las cosas no se cambien accidentalmente. Entonces, las pruebas ayudan allí al mostrar si algo ha cambiado inadvertidamente, y le muestran exactamente qué se vio afectado por el cambio.

Answer 2

unidad de pruebas podría convertirse en gran medida innecesaria debido al hecho de que el código está cerrado a la modificación

Bueno, no del todo. ¿Cómo sabes que la implementación original, cerrada, es correcta?

El beneficio a largo plazo del costo inicial agregado de las pruebas unitarias se pierde

Un hallazgo importante de la economía de la ingeniería de software es que es mucho más costoso para detectar y corregir un defecto más tarde en la vida de una producto. IIRC, por un orden de magnitud para cada etapa en un proceso clásico de desarrollo de "cascada". Como las pruebas unitarias (ya sea TDD o prueba primero) detectan los defectos de manera temprana, pueden recuperar rápidamente sus costos.

no va a cambiar

Si tiene un defecto en ella tendrá que ser cambiado. Por supuesto, si puede garantizar que su código no contenga defectos, lo que diga es cierto. Pero si puede garantizar que no necesita ningún tipo de prueba. Pero muy pocos proyectos de software pueden hacer tal afirmación.