Prueba de código iterativo usando simulacros: ¿tiene sentido, cómo?

Question

Quiero probar un algoritmo usando simulacros. El algoritmo, en la implementación actual, itera sobre una clase de contenedor en múltiples pases y set () s y get () s valores de él. El propósito de la prueba es verificar el resultado final, almacenado en el contenedor. El valor final depende de los valores leídos y escritos entre los pases. Por ejemplo, el valor de cualquier elemento puede cambiar varias veces hasta que el algoritmo esté terminado y, más probable, su valor como resultado de la iteración n dependerá de su valor después de la iteración N-1.

Me gusta la idea de simulacros y me encantaría usarlos en el escenario descrito anteriormente, ya que me permitiría verificar el comportamiento erróneo del algoritmo una vez que ocurra, no solo cuando el cálculo está terminado. Sin embargo, no estoy seguro de si esto sería realmente una buena idea porque tendría que vincular las expectativas para el simulacro de la implementación actual (por ejemplo ", espere obtener (elemento n) y return x, luego establecer ( elemento n, valor x+1), otro get (n) y return x+1, luego espere establecer (n, x+2) etc. ").

Aunque me permite verificar que los valores intermedios son los esperados, creo que tales expectativas contradecirían el propósito de la prueba (verifique que el algoritmo calcule el valor final correcto) y probablemente la prueba falle si la implementación cambia, independientemente de la corrección de el valor final.

Ahora mi pregunta: ¿me estoy perdiendo algo? ¿Hay una buena manera de usar simulacros en este escenario? ¿O simplemente no tiene sentido usarlos aquí? ¿Cómo tratan los demás con este problema?

Comentario final: estoy hablando de probar el código C ++ y usar Googlemock, si eso hace alguna diferencia en su respuesta.

PD: Revisé Google y artículos aquí (especialmente Burlarse del comportamiento iterativo - Solo aborda el problema de aumentar un valor de retorno), sin embargo, no encontré nada cercano a mi problema.

Answer 1

Diría que si el contenedor es lento de alguna manera o tiene efectos secundarios que significan que no puede leer sus valores sin molestarlo, entonces debe usar un simulacro.

De lo contrario, usar un simulacro es una pérdida de tiempo. ¿Usarías una versión burlada de std::vector? Yo no lo haría; Sería una tontería.

Con sus pruebas unitarias, si no puede probar todo el estado interno de su algoritmo a través de varios parámetros públicos, entonces esos estados en realidad no importan. Nunca pueden aparecer en uso real. Entonces, siempre que obtenga la respuesta final correcta de su algoritmo para cada conjunto de parámetros de entrada, diría que las cosas funcionan bien.

Answer 2

Cree su prueba unitaria para la salida final del algoritmo. Desea que sus pruebas automatizadas verifiquen el resultado esperado porque eso es lo que otras partes del programa utilizarán.

En cuanto a probar los pasos individuales dentro del código de algoritmo, este es más un trabajo para avanzar con un depurador, no para pruebas automatizadas. Pasar por el funcionamiento interno del algoritmo debe ser algo único, y una vez que lo tenga, no es necesario seguir probando pasos individuales dentro de él.

Answer 3

Las pruebas unitarias serían más aplicables en las partes más pequeñas que componen el algoritmo.

Dicho esto, las herramientas de prueba unitaria son muy útiles para desarrollar algoritmos de esa manera. No son nada malos de usar, simplemente no se lo aferren si ya no son válidos. Por lo general, no probaría cada iteración en una prueba de integración, solo probaría los resultados. Sin embargo, si es útil desarrollar el algoritmo de esa manera, hágalo.

Tienes razón sobre los simulacros, en realidad no estás probando mucho. Sin embargo, pueden ser útiles si desea controlar algunas de las entradas. Muchas veces permitiré mis entradas de manera exhaustiva cuando tengo cajas negras que no puedo controlar. Sin embargo, este tipo de pruebas funcionan demasiado tiempo. Generalmente los comentaré de manera total o parcial cuando entran en el control de la fuente.