¿Cuáles son los beneficios de las pruebas unitarias de software altamente crítico?

Si necesita estar convencido del valor de las pruebas unitarias en general, no solo para los sistemas de misión crítica, entonces puede encontrar su respuesta aquí: mi empleador me dijo que no escribiera pruebas unitarias para que pudiéramos lanzar el software más rápido. ¿Tiene razón?

Si ya está convencido, creo que la verdadera pregunta es ¿cuánto más debe pagar por las unidades que prueban su sistema de misión crítica, en comparación con su sistema no crítico? ¿Cómo equilibra esta inversión con la inversión en otro tipo de pruebas?

Algunas cosas para tener en mente:

Al construir un sistema de misión crítica, gran parte de la energía y los recursos deben dedicarse a la calidad. Simplemente no puede permitirse el lujo de los errores que afectan al usuario.

Las pruebas unitarias no son la mejor herramienta para encontrar errores que impactan al usuario . Incluso con una cobertura de prueba del 100%, se puede enviar un software horrible que está lleno de errores. Las pruebas unitarias aseguran que una clase o una función haga lo que debería donde se burlan todas las dependencias. Las pruebas unitarias no cubren los escenarios de integración, donde todos los componentes están conectados entre sí y hacen uso de dependencias externas.

Las mejores herramientas para encontrar errores y garantizar la calidad son (no se limitan a) pruebas funcionales de extremo a extremo, pruebas exploratorias, uso del software en entornos de preproducción, recopilación de telemetría y uso para evaluar la calidad.

Las pruebas unitarias son críticas para construir un sistema de software saludable, donde el estado del software se mide principalmente por el nivel de mantenimiento del código. Es esencial para construir una tubería efectiva de integración / entrega continua, que (en combinación con otros medios) le permitirá realizar cambios de manera mucho más efectiva.

Es importante que su sistema de misión crítica sea saludable, ya que es más fácil construir un sistema de calidad cuando la base de código es mantenible y fácil de entender (especialmente a escala). Por lo tanto, debe (y la mayoría de la gente lo hace) aspirar a una convergencia de prueba de unidad superior a la normal.

Tómese el tiempo para medir la cobertura de la prueba unitaria, pero tenga en cuenta que está midiendo el estado del software, no la calidad del software.

Cambiaría esta pregunta: ¿alguna vez es viable no probar su software antes de entregarlo a alguien? ¿Cómo puede afirmar que su unidad de software funciona según lo previsto? ¿Que has hecho bien tu trabajo?

Diría que los beneficios son principalmente para su carrera como desarrollador de software.

Sin pruebas, no sabes lo que tienes, qué errores tontos has cometido, qué descuidos cometiste en el diseño o la implementación. También indica que ha pensado poco o nada acerca de cómo se debe probar su software, lo que podría indicar que será difícil de probar. En ese caso, su carrera de ingeniería de software puede no ser viable, ya que indicaría a sus pares y a la gerencia que no le importa si el software que escribe funciona correctamente o no.

El equipo de prueba independiente está destinado a actuar como un segundo par de ojos y comprobar que el sistema en su conjunto funciona bien. Esperemos que las únicas fallas que encuentren se deban a problemas de integración debido a diferentes interpretaciones de las especificaciones.

Y, por supuesto, aún no he mencionado el beneficio principal de las pruebas unitarias, o más exactamente, el desarrollo impulsado por pruebas: al diseñar las pruebas antes de escribir una línea de código, te obligas a aclarar por completo los requisitos, eliminando mucha ambigüedad potencial en esos requisitos Ver desarrollo impulsado por pruebas | Wikiwand.