¿Cuáles son las ventajas tangibles de las pruebas unitarias adecuadas sobre las pruebas funcionales llamadas pruebas unitarias?

Un proyecto en el que estoy trabajando tiene un montón de pruebas heredadas que no se burlaron correctamente. Debido a esto, la única dependencia que tiene es EasyMock, que no admite estática, constructores con argumentos, etc. Agregar Powermock para manejar estos casos está siendo eliminado como un costo prohibitivo debido a la necesidad de actualizar el proyecto existente para respaldarlo (Otra discusión).

Mis preguntas son, ¿cuáles son los beneficios tangibles del mundo REAL de las pruebas unitarias adecuadas que puedo usar para retrasar? ¿Hay alguna? ¿Estoy siendo un fanático al decir que las malas pruebas unitarias (incluso si funcionan) son malas? ¿La cobertura del código es igual de efectiva?

• Recursos

  Necesita una base de datos de prueba para ejecutar las pruebas. El hardware para ejecutar la base de datos es más costoso que usar powermock. La liberación de los recursos utilizados para las pruebas unitarias contra la base de datos significa que la empresa no necesita actualizar el servidor tan pronto.

• Fiabilidad

  Una prueba puede fallar porque la base de datos está inactiva o en un estado inconsistente. Adivina qué, tus compilaciones fallaron porque los DBA desactivaron el servidor de desarrollo durante el día para hacer algunas actualizaciones (y ahora los desarrolladores están tratando de descubrir qué salió mal en el código, cuando no es el código).

• Mantenimiento adicional

  Las pruebas se pueden ejecutar en cualquier orden. Agregar o eliminar una prueba no debe causar que falle el conjunto de pruebas. Correr contra una base de datos significa que hay algún estado en alguna parte (en la base de datos). Por lo general, estas pruebas requieren un mantenimiento adicional para garantizar que la base de datos mantenga el estado adecuado para que se ejecute la siguiente prueba.

• Concurrencia

  Dos desarrolladores ejecutan las pruebas unitarias al mismo tiempo. Tener una base de datos significa que las pruebas pueden colisionar en la base de datos. La solución a esto sería clonar la base de datos para cada prueba que se ejecute, lo cual es prohibitivo en una base de datos real. Lo que lleva a otra opción a considerar.

Considere también usar HSQLDB con cualquier dialecto de la base de datos que esté usando. De esta manera, se puede crear una base de datos en memoria para cada prueba. Se ejecuta una prueba unitaria, construye la base de datos necesaria, carga los datos, la conexión de la base de datos del código se conecta a HSQLDB y se ejecuta contra los datos de la prueba.

Mis preguntas son, ¿cuáles son los beneficios tangibles del mundo REAL de las pruebas unitarias adecuadas que puedo usar para retrasar?

Las buenas pruebas unitarias son (según Clean Code y en otros lugares):

• Rápido
• Independiente
• Repetible
• Autovalidante
• Oportuno

No tener pruebas unitarias verdaderas viola las tres primeras (y generalmente la última). Esto lleva a algunos problemas bastante importantes:

1. Tus pruebas son lentas. Las pruebas lentas se ejecutan con poca frecuencia. Las pruebas que no se ejecutan son casi inútiles.
2. Sus pruebas pueden fallar debido a razones no relacionadas con el código que está probando. Esto hace que sea mucho más difícil descubrir por qué las pruebas han fallado, desperdiciando tiempo y llevando a las personas a culpar al medio ambiente en lugar del código.
3. A medida que cambia la base de datos, cambian sus resultados. Obtener una base de datos en un estado conocido, consistente y mantenido para las pruebas es tedioso, molesto y propenso a errores.

En general, la falta de aislamiento en las pruebas unitarias conduce a peores pruebas que toman más tiempo para escribir, más tiempo para investigar y proporcionan menos confianza en su código base. Eso a su vez lleva a que las personas escriban menos pruebas o ignoren más las pruebas, que es la espiral descendente hacia el caos.

Las pruebas unitarias son solo una herramienta utilizada para ayudar a un desarrollador a entregar un código confiable. Si piensas como piensa tu jefe, podrás convencerlo si lo que estás proponiendo tiene sentido. Sin embargo, si lo presenta como un evangelista en un carro de la banda, no obtendrá los recursos asignados. Deberá explicarle cómo se beneficia al dedicar el tiempo y los recursos a las pruebas unitarias de su aplicación heredada.

Usted mencionó las pruebas heredadas, eso implica código heredado. Desafortunadamente, ajustar las pruebas unitarias al código que no fue diseñado para ser probado es un proceso difícil, lento y costoso. El caso de negocios se vuelve aún más difícil si tiene pruebas que brindan resultados útiles, y todo lo que va a lograr es (a partir del POV del caso de negocios) pruebas alternativas que brinden los mismos resultados. Deberá concentrarse en el ahorro de costos (tiempo) .....

Supongo que no podrá presentarle a su jefe un caso comercial sólido porque no hay ninguno.

Por lo que describió, parece que no le gusta el marco de prueba A y desea cambiar al marco de prueba B, que funcionan. Aspire y use lo que existe y funciona, no cree más trabajo reinventando la rueda para que pueda usar su marco de prueba preferido.

Se necesita más que un deseo de usar la última versión del marco del mes para justificar el desecho del código de trabajo existente y gastar enormes cantidades de tiempo y dinero para un beneficio esencialmente cero para los usuarios.

Las buenas pruebas unitarias proporcionan localización. Las pruebas funcionales pueden decirle "la función de agregar usuario está rota", pero una buena prueba de unidad le dirá que está rota porque alguien cambió el campo USER.LAST_NAME en la base de datos para que no sea nulo. También es posible probar pequeños cambios directamente, en lugar de necesitar un entorno de prueba complejo (que puede necesitar reinicializarse o purgarse para algunas pruebas).