Primero, acordemos que la "prueba de unidad" se usa a menudo para cubrir todas las pruebas automáticas que escribe un programador, y que no tiene sentido debatir cómo debería llamarse cada prueba ...
He trabajado en un sistema donde el software tomó muchas entradas y resolvió una "solución" que tenía que cumplir algunas restricciones, mientras optimizaba otros números. No hubo respuestas correctas, por lo que el software solo tuvo que dar una respuesta razonable.
Hizo esto usando muchos números aleatorios para obtener un punto de partida, luego usó un "escalador" para mejorar el resultado. Esto se ejecutó muchas veces, escogiendo el mejor resultado. Se puede sembrar un generador de números aleatorios, de modo que siempre dé los mismos números en el mismo orden, por lo tanto, si la prueba establece una semilla, sabemos que el resultado sería el mismo en cada ejecución.
Tuvimos muchas pruebas que hacían lo anterior y verificamos que los resultados eran los mismos, esto nos dijo que no habíamos cambiado lo que esa parte del sistema hizo por error al refactorizar, etc. No nos dijo nada sobre la corrección de lo que hizo esa parte del sistema.
Estas pruebas fueron costosas de mantener, ya que cualquier cambio en el código de optimización interrumpiría las pruebas, pero también encontraron algunos errores en el código mucho más grande que preprocesó los datos y procesó los resultados posteriormente.
Como nos "burlamos" de la base de datos, podría llamar a estas pruebas "pruebas unitarias", pero la "unidad" era bastante grande.
A menudo, cuando estás trabajando en un sistema sin pruebas, haces algo como lo anterior, para que puedas confirmar que tu refactorización no cambia la salida; Esperemos que se escriban mejores pruebas para el nuevo código!