¿Pruebas unitarias de grandes conjuntos de datos?

Question

¿Cuál es la mejor manera de probar unitariamente grandes conjuntos de datos? Algunos códigos heredados que mantengo tienen estructuras de cien miembros o más; otras partes del código en las que estamos trabajando crean o analizan conjuntos de datos de cientos de muestras.

El mejor enfoque que he encontrado hasta ahora es serializar las estructuras o conjuntos de datos del disco, realizar las operaciones bajo prueba, serializar los resultados en el disco, y luego diferenciar los archivos que contienen los resultados serializados contra los archivos que contienen los resultados esperados. Esto no es terriblemente rápido, y viola el " no toque el disco " principio de pruebas unitarias. Sin embargo, la única alternativa que se me ocurre (escribir código para inicializar y probar cientos de miembros y puntos de datos) parece insoportablemente tediosa.

¿Hay alguna solución mejor?

Answer 1

Si lo que está tratando de lograr es, de hecho, una prueba unitaria, debe simular las estructuras de datos subyacentes y simular los datos. Esta técnica le da un control completo sobre las entradas. Por ejemplo, cada prueba que escriba puede manejar un único punto de datos y tendrá un conjunto de pruebas muy conciso para cada condición. Existen varios marcos de burla de código abierto, personalmente recomiendo Rhino Mocks ( http: // ayende.com/projects/rhino-mocks/downloads.aspx ) o NMock ( http: //www.nmock .org ).

Si no es posible que te burles de las estructuras de datos, te recomiendo refactorizar para que puedas :-) ¡Vale la pena! O también puede probar TypeMock ( http://www.typemock.com/ ) que permite la burla de clases concretas.

Sin embargo, si está haciendo pruebas contra grandes conjuntos de datos, realmente está ejecutando pruebas funcionales, no pruebas unitarias. En cuyo caso, cargar datos en una base de datos o desde un disco es una operación típica. En lugar de evitarlo, debe trabajar para que se ejecute en paralelo con el resto de su proceso de compilación automatizado para que el impacto en el rendimiento no detenga a ninguno de sus desarrolladores.

Answer 2

Esto sigue siendo un enfoque viable. Sin embargo, clasificaría esto como una prueba funcional, o simplemente no como una prueba unitaria pura. Una buena prueba de unidad sería tomar una muestra de esos registros que den una buena distribución de los casos de borde que pueda encontrar, y escribirlos. Entonces, tienes tu última " aceptación " o "funcional" prueba con tu prueba masiva de todos los datos.

He utilizado este enfoque cuando estoy probando grandes cantidades de datos, y encuentro que funciona lo suficientemente bien porque las unidades pequeñas son mantenibles, y luego sé que la prueba masiva funciona, y todo es automático.

Answer 3

  

El mejor enfoque que he encontrado hasta ahora es serializar las estructuras o conjuntos de datos del disco, realizar las operaciones bajo prueba, serializar los resultados en el disco, y luego diferenciar los archivos que contienen los resultados serializados contra los archivos que contienen los resultados esperados.

He escrito código que usa la técnica anterior, excepto que en lugar de serializar desde el disco en la prueba, he convertido los datos serializados en una matriz de bytes que el compilador puede colocar en el ejecutable para usted.

Por ejemplo, sus datos serializados se pueden convertir en:

unsigned char mySerialisedData[] = { 0xFF, 0xFF, 0xFF, 0xFF, ... };

test()
{
    MyStruct* s = (MyStruct*) mySerialisedData;

}

Para un ejemplo más detallado (en C #) vea esto prueba de unidad . Muestra un ejemplo de uso de algunos datos serializados codificados como entrada para pruebas, prueba de firma de ensamblaje.