Escritura de pruebas para el código existente

Si bien las pruebas son una buena idea, la intención era que el codificador original las construya, ya que estaba construyendo la aplicación para capturar su conocimiento de cómo se supone que funciona el código y qué se puede romper. que luego te habrían transferido.

Al adoptar este enfoque, existe una alta probabilidad de que esté escribiendo las pruebas que tienen menos probabilidades de interrumpir, y perderá la mayoría de los casos de borde que se hubieran descubierto al compilar la aplicación.

El problema es que la mayor parte del valor provendrá de esos 'errores' y situaciones menos obvias. Sin esas pruebas, el conjunto de pruebas pierde prácticamente toda su eficacia. Además, la compañía tendrá una falsa sensación de seguridad con respecto a su aplicación, ya que no será significativamente más resistente a la regresión.

Por lo general, la forma de manejar este tipo de base de código es escribir pruebas para el nuevo código y para refactorizar el código antiguo hasta que la base de código heredada sea completamente refacta.

También ver .

Sí, agregar pruebas es definitivamente una buena idea.

Usted dice que está bien documentado y eso lo coloca en una buena posición. Intente crear pruebas utilizando esa documentación como guía, centrándose en partes del sistema que son críticas o están sujetas a cambios frecuentes.

Inicialmente, el tamaño total de la base de código probablemente parecerá abrumador en comparación con la pequeña cantidad de pruebas, pero no hay un enfoque de gran explosión, y hacer un comienzo en algún lugar es más importante que agonizar sobre El mejor enfoque será.

Recomendaría el libro de Michael Feathers, Trabajar de manera efectiva con el código heredado , para obtener consejos buenos y detallados.

No todas las pruebas unitarias tienen el mismo beneficio. El beneficio de una prueba de unidad viene cuando falla. Cuanto menos probable es que falle, menos beneficioso es. Es más probable que los códigos nuevos o modificados recientemente contengan errores que los códigos raramente modificados que se han probado bien en producción. Por lo tanto, es más probable que las pruebas unitarias en códigos nuevos o recientemente modificados sean más beneficiosas.

No todas las pruebas unitarias tienen el mismo costo. Es mucho más fácil probar el código trivial que diseñó usted mismo hoy que el código complejo que alguien más diseñó hace mucho tiempo. Además, las pruebas durante el desarrollo generalmente ahorran tiempo de desarrollo. En el código heredado, los ahorros de costos ya no están disponibles.

En un mundo ideal, tendría todo el tiempo que necesita para hacer una prueba unitaria del código heredado, pero en el mundo real, en algún momento es lógico que los costos de agregar pruebas unitarias al código heredado superen los beneficios . El truco es identificar ese punto. Su control de versión puede ayudar al mostrarle el código más recientemente modificado y cambiado con mayor frecuencia, y puede comenzar poniéndolos a prueba de unidad. Además, cuando haga cambios en el futuro, ponga esos cambios y el código relacionado en la prueba de unidad.

Siguiendo ese método, finalmente tendrás una buena cobertura en las áreas más beneficiosas. Si en cambio pasa meses implementando pruebas unitarias antes de reanudar las actividades generadoras de ingresos, esa podría ser una decisión de mantenimiento de software deseable, pero es una decisión comercial pésima.

  

¿Es una buena idea agregar pruebas?

Absolutamente, aunque me resulta un poco difícil creer que el código esté limpio, funcione bien y utilice técnicas modernas y simplemente no tenga pruebas unitarias. ¿Estás seguro de que no están sentados en una solución independiente?

De todos modos, si vas a extender / mantener el código, las verdaderas pruebas de unidad son invaluables para ese proceso.

  

Si es así, ¿cómo se podría empezar con algo como esto?

Un paso a la vez. Si no está familiarizado con las pruebas de unidad, aprenda un poco. Una vez que se sienta cómodo con los conceptos, elija una pequeña sección del código y escriba pruebas para ello. Luego lo siguiente, y lo siguiente. La cobertura del código puede ayudarlo a encontrar los lugares que ha perdido.

Probablemente sea mejor elegir cosas peligrosas / arriesgadas / vitales para probar primero, pero podría ser más efectivo probar algo sencillo para entrar primero en un surco, especialmente si usted / el equipo no está acostumbrado a la base de código y / o pruebas unitarias.

Sí, tener pruebas es una buena idea. Ayudarán a documentar las bases de código existentes según lo previsto y detectar cualquier comportamiento inesperado. Incluso si las pruebas inicialmente fallan, déjelas y luego refactorice el código más adelante para que pasen y se comporten según lo previsto.

Comience a escribir pruebas para clases más pequeñas (las que no tienen dependencias y son relativamente simples) y continúe con clases más grandes (las que tienen dependencias y son más complejas). Tomará mucho tiempo, pero sea paciente y persistente para que eventualmente pueda cubrir la base de código tanto como sea posible.

Está bien, voy a dar la opinión contraria ...

Agregar pruebas a un sistema existente y funcional va a alterar ese sistema, a menos que sea así, todo el sistema está escrito con burlas en mente desde el principio. Lo dudo, aunque es bastante posible que tenga una buena separación de todos los componentes con límites fácilmente definibles en los que puede deslizar sus interfaces simuladas. Pero si no lo es, entonces tendrá que hacer cambios bastante significativos (relativamente hablando) que podrían romper las cosas. En el mejor de los casos, pasará una cantidad de tiempo escribiendo estas pruebas, tiempo que podría dedicarse mejor a escribir una carga de documentos de diseño detallados, documentos de análisis de impacto o documentos de configuración de soluciones. Después de todo, ese es el trabajo que su jefe quiere hacer más que pruebas de unidad. ¿No es así?

De todos modos, no agregaría ninguna prueba de unidad alguna.

Me concentraría en herramientas de prueba externas y automatizadas que le brindarán una cobertura razonable sin cambiar nada. Luego, cuando llegue a realizar modificaciones ... es cuando puede comenzar a agregar pruebas unitarias dentro de la base de código.

A menudo me he topado con esta situación, heredé una base de código grande sin una cobertura de prueba adecuada o sin cobertura, y ahora soy responsable de agregar funcionalidad, corregir errores, etc.

Mi consejo es que se asegure y pruebe lo que agrega, y si corrige errores o modifica los casos de uso en el código actual, las pruebas del autor entonces. Si tienes que tocar algo, escribe pruebas en ese punto.

Cuando esto se rompe es cuando el código existente no está bien estructurado para las pruebas unitarias, por lo que dedicas mucho tiempo a la refactorización para que puedas agregar pruebas para cambios menores.