¿Cuál es la relevancia de las pruebas unitarias en un entorno de "Publicación temprana de liberación frecuente"?

Durante el último año más o menos, he llevado a mi equipo hacia el modo de desarrollo lanzamiento-lanzamiento-lanzamiento-a menudo (AKA: Desarrollo rápido de aplicaciones, no ágil). Para obtener más información sobre la forma en que cerramos la compilación, consulte mi respuesta aquí: Una forma sencilla de mejorar la calidad de la versión en el entorno RAD

Cuando adoptamos RAD, las personas eran bastante independientes y estaban haciendo pruebas unitarias primero; Las pruebas integradas ocurrieron mucho más tarde en el proceso. Fue un proceso natural para ellos sin mucha aplicación formal. Ahora la situación es bastante diferente:

1. Toda la plataforma está bien integrada con compilaciones / lanzamientos establecidos que funcionan en el lado del cliente sin puntos críticos.

2. Los nuevos requisitos de funcionalidad siguen llegando y los creamos gradualmente a medida que avanzamos.

3. La dinámica general del sistema es muy importante porque, si bien los grupos de desarrollo independientes pueden estar siguiendo los procesos correctamente, han surgido fallas importantes debido a circunstancias complicadas y no obvias.

4. Muchas partes del sistema involucran nuevos algoritmos e insumos de investigación, por lo que los desafíos (y, por lo tanto, el mecanismo de prueba) no siempre se prevén correctamente, como las pruebas de características en software bien definido.

Recientemente, estaba tratando de obtener una mejor imagen general para ver si necesitamos mejorar el proceso. Cuando me senté con mi equipo, muchos de ellos se negaron: "¡Ya no hacemos pruebas unitarias!" mientras que otros pensaron que no deberíamos comenzar ahora porque nunca será efectivo.

¿Son útiles las pruebas unitarias en un sistema relativamente maduro? ¿Deberíamos al menos tener que sopesar el alcance de la prueba dependiendo de la madurez de las unidades? ¿Las pruebas unitarias ralentizarán el ritmo de desarrollo? ¿Es necesario evaluar las pruebas unitarias de una manera diferente?

¿Cuáles son las mejores prácticas de prueba para una plataforma madura en un entorno de lanzamiento-lanzamiento-temprano-a menudo?

Las pruebas unitarias no son principalmente para encontrar errores en primer lugar, sino para garantizar que la próxima versión de su sistema sea tan estable como la versión anterior. Cuanto más corto sea su ciclo de lanzamiento, más importante será que pueda ejecutar estas pruebas automáticamente en lugar de hacerlo manualmente.

Por supuesto, si tiene un sistema con algunas partes independientes, y estaba trabajando entre dos versiones solo en una pequeña porción del sistema, probablemente puede omitir algunas pruebas unitarias que son para otras partes del sistema. Pero definitivamente debe usar (y extender) las pruebas unitarias para las partes en las que está trabajando.

Otra cosa es que cuando un sistema crece, habrá una necesidad cada vez mayor de pruebas de integración adicionales , pero eso no significa que necesitará menos pruebas unitarias.

La verdadera pregunta detrás de la suya puede ser otra. ¿Se ha vuelto más difícil escribir pruebas unitarias desde que su sistema se ha vuelto cada vez más grande? ¿Sus pruebas de "unidad" son realmente pruebas de unidad, o ya no prueban las cosas de forma aislada? Esto puede deberse a que dependen de partes del sistema de nivel inferior que se han estabilizado con el tiempo.

Estas cosas suceden porque los desarrolladores tienden a reutilizar las bibliotecas y el código existentes al hacer referencia directa a ellos. A menudo tiene el efecto de que las pruebas unitarias de escritura se vuelven más difíciles, ya que a menudo tienen que proporcionar un entorno más complejo y más datos de prueba. Si ese es su problema, entonces debe aprender sobre los conceptos clave Inyección de dependencia y Principio de segregación de interfaz , que pueden ayudarlo a hacer que el código sea más comprobable por unidad.

Debería considerar investigar el desarrollo basado en pruebas, donde las pruebas se diseñan primero y describen cómo funcionará el nuevo código cuando se escriba. Luego haces pasar las pruebas.

En mi experiencia, esto tiende a hacer un código más ágil y mejor pensado, especialmente para las bibliotecas, y es una parte ejecutable de la especificación (lo que significa que siempre será la documentación correcta).

Dicho esto, las pruebas existentes se utilizan para garantizar que el código siga funcionando como se esperaba. Puede detectar la rotura del código y le permite asegurarse de que el código de terceros todavía funciona como se esperaba al actualizar.

Según lo sugerido por Doc Brown y Thorbjørn Ravn Andersen , un entorno de lanzamiento temprano a menudo puede beneficiarse aún más de las buenas pruebas unitarias y el desarrollo impulsado por pruebas que uno con ciclos de lanzamiento largos.

Si tiene un buen sistema de integración continua y pruebas que representan bien la funcionalidad, tiene una buena idea en cualquier momento de lo que está funcionando (porque las pruebas para esa funcionalidad están pasando) y lo que aún no se ha implementado ( porque no hay pruebas para esa funcionalidad).