¿Cuáles son las desventajas al usar valores aleatorios en Pruebas unitarias?

Question

Me gustaría saber cuáles son las desventajas de usar valores aleatorios en algunas de las pruebas unitarias.

---

Estoy hablando de un sistema de gran escala, con muchos servidores y entrada no determinista en alta capacidad. cuando digo no determinista, estoy hablando de mensajes que se envían y captas lo que puedes y haces lo mejor que puedes. Hay muchos tipos de mensajes, por lo que la entrada puede ser muy complicada. No me puedo imaginar escribiendo el código para tantos escenarios y un generador de mensajes simples no aleatorios (determinísticos) no es lo suficientemente bueno. Es por eso que quiero tener una prueba unitaria aleatorizada o una prueba de servidor que en caso de falla podría escribir un registro. Y prefiero la prueba unitaria en lugar de un inyector aleatorio porque quiero que se ejecute como parte de las pruebas automáticas de compilación nocturna.

Answer 1

Desventajas

En primer lugar, se hace la prueba más complicado y un poco más difícil de depurar, ya que no puede ver directamente todos los valores que se alimentan en (aunque siempre existe la opción de generar casos de prueba como código o datos, también). Si está haciendo una lógica semi-complicada para generar sus datos de prueba aleatorios, también existe la posibilidad de que este código tenga un error. Los errores en el código de prueba pueden ser un problema, especialmente si los desarrolladores asumen inmediatamente que el error es el código de producción.

En segundo lugar, a menudo es imposible ser específico sobre la respuesta prevista. Si conoce la respuesta basada en la entrada, entonces hay una posibilidad decente de que solo esté aplicando la lógica bajo prueba (piénselo, si la entrada es aleatoria, ¿cómo conoce la salida esperada?) Como resultado, usted puede tener que negociar aseveraciones muy específicas (el valor debe ser x) para afirmaciones más generales de control de cordura (el valor debe estar entre y y z).

En tercer lugar, a menos que haya una amplia gama de entradas y salidas, a menudo puede cubrir el mismo rango utilizando valores bien elegidos en una unidad estándar de pruebas con menos complejidad. P.ej. elige los números -max, (-max + 1), -2, -1, 0, 1, 2, max-1, máx. (o lo que sea interesante para el algoritmo).

Upsides

Cuando se hace bien con el objetivo correcto, estas pruebas pueden proporcionar una muy valiosa pase las pruebas complementarias. He visto bastantes bits de código que, cuando son martillados por entradas de prueba generadas al azar, se abrochan debido a casos de bordes imprevistos. A veces agrego un pase de prueba de integración adicional que genera una carga de casos de prueba.

trucos adicionales

Si uno de sus pruebas al azar falla, aislar el valor 'interesante' y promover en una unidad de prueba independiente para asegurar que se puede corregir el error y nunca lo hará retroceder antes de registrar .

Answer 2

Son aleatorios.

(Usted podría funcionar prueba al azar, incluso si su código está roto.)

Answer 3

Además, usted no será capaz de reproducir las pruebas muchas veces. Una prueba de unidad debe ejecutarse exactamente igual con los parámetros dados.

Answer 4

Los resultados no son repetibles, y dependiendo de sus pruebas, es posible que no conozca las condiciones específicas que causaron el error del código (lo que dificulta su depuración).

Answer 5

Es mucho mejor tener pruebas unitarias que sean 100% repetibles e incluyan todos los casos extremos. Por ejemplo, prueba cero, negativos, positivos, números demasiado grandes, números demasiado pequeños, etc. Si deseas incluir pruebas con valores aleatorios además de todos los casos extremos y casos normales, estaría bien. Sin embargo, no estoy seguro de que obtendría un gran beneficio del tiempo invertido. Tener todos los casos normales y casos extremos debe manejar todo. El resto es "salsa".

Answer 6

Como han sugerido otros, hace que su prueba no sea confiable porque no sabe lo que sucede dentro de ella. Eso significa que podría funcionar en algunos casos, y no en otros.

Si ya tiene una idea del rango de valores que desea probar, entonces debe (1) crear una prueba diferente para cada valor en el rango, o (2) repetir el conjunto de valores y hacer una afirmación en cada iteración. Un ejemplo rápido, bastante tonto ...

for($i = 0; $i < 10; $i++) 
    $this->assertEquals($i + 1, Math::addOne($i)); 

Podría hacer algo similar con las codificaciones de caracteres. Por ejemplo, recorra el conjunto de caracteres ASCII y pruebe todos esos caracteres locos contra una de las funciones de manipulación de texto.

Answer 7

Debe recordar qué números aleatorios generó durante la verificación.

Ejemplo.

Username= "username".rand(); 
Save_in_DB("user",Username); // To save it in DB 
Verify_if_Saved("user",Username); 

Answer 8

Creo que la generación de valores de entrada aleatorios puede ser una técnica de prueba confiable cuando se usa junto con la partición de equivalencia. Esto significa que, si particiona su espacio de entrada y luego selecciona al azar los valores de una clase de equivalencia, entonces está bien: la misma cobertura (cualquiera de ellos, incluida la declaración, la rama, todos los usos, etc.). Esto bajo la suposición de que su procedimiento de partición de equivalencia es correcto. Además, recomendaría el análisis del valor límite para emparejarlo con la partición de equivalencia y las entradas generadas aleatoriamente.

Finalmente, también recomendaría considerar el TIPO de defectos que desea detectar: ​​algunas técnicas de prueba abordan tipos específicos de defectos, que pueden ser difíciles de detectar (y por casualidad) por otras técnicas. Un ejemplo: condiciones de punto muerto.

En conclusión, creo que generar valores aleatorios no es una mala práctica, en particular en algunos sistemas (por ejemplo, aplicaciones web), pero solo aborda un subconjunto de defectos existentes (como cualquier otra técnica) y uno debe saber de eso, para complementar su proceso de garantía de calidad con el conjunto adecuado de actividades.

Answer 9

Las pruebas de unidades aleatorias utilizan un destornillador para clavar un clavo. El problema no es que los destornilladores sean malos; el problema es que estás usando la herramienta incorrecta para el trabajo. El objetivo de las pruebas unitarias es proporcionar retroalimentación inmediata cuando rompes algo, para que puedas arreglarlo allí mismo.

Digamos que compromete un cambio, que llamaremos BadChange. BadChange presenta un error, que algunas veces tus pruebas aleatorias detectarán y otras no. Esta vez, las pruebas no lo atrapan. BadChange se le da todo claro y entra en la base de código.

Más tarde, alguien comete otro cambio, GoodChange. GoodChange está cien por ciento bien. Pero esta vez, tus pruebas aleatorias captan el error introducido por BadChange. Ahora GoodChange está marcado como un problema, y ​​el desarrollador que lo escribió irá en círculos tratando de descubrir por qué este cambio inocuo está causando problemas.

Las pruebas aleatorias son útiles para examinar constantemente toda la aplicación en busca de problemas, no para validar cambios individuales. Debería vivir en una suite separada, y las ejecuciones no deberían estar vinculadas a cambios de código; incluso si nadie ha hecho un cambio, existe la posibilidad de que las pruebas aleatorias se topen con algún error exótico que fallaron las corridas anteriores.

Answer 10

Upsides: revelan cuando sus otras pruebas tienen no cubrieron todas las invariantes. Si desea que su servidor de CI ejecute pruebas no determinantes es otro problema. Dado lo increíblemente útil que he encontrado https://www.artima.com/shop/scalacheck, no pretendo prescindir de él a partir de ahora. Supongamos que está implementando un algoritmo de coincidencia de patrones. ¿Conoces realmente todos los diferentes casos de esquina? Yo no. Las entradas aleatorias pueden expulsarlos.

Answer 11

Adicional DownsideDownside Adicional que no ha sido mencionado aún es que sus pruebas pueden fallar intermitentemente al azar, especialmente cuando genera aleatoriamente varias variables de prueba para que formen unas dependencias intrincadas y, a veces, imposibles de eludir. Vea el ejemplo here.

Depuración estos es un dolor en la parte trasera y a veces es (al lado de) imposible.

Además, a menudo es difícil decir lo que realmente prueba su prueba (y si prueba algo en absoluto).

Históricamente en mi compañía usamos pruebas aleatorias en múltiples niveles (Unidad, Integración, Pruebas de servicio único), y eso pareció una gran idea inicialmente: le ahorra código, espacio y tiempo permitiendo probar múltiples escenarios en una prueba.

Pero cada vez más eso llega a ser un punto pegajoso en nuestro desarrollo, cuando nuestra prueba (incluso histórica y fiable en el pasado) comienza a fallar al azar, y la fijación de estos es mucho trabajo.