Datos de prueba de unidad grande

Question

Recientemente escribí un conjunto de pruebas unitarias que se basaban en un gran conjunto de datos de prueba. El conjunto contenía doce elementos y aunque esto no parece mucho, fue cuando se usó con las pruebas.

Cada elemento requiere varias propiedades para establecerse con valles únicos. El problema con este método fue que el método de fábrica que creó este conjunto de datos era enorme.

¿Cuáles son las mejores prácticas con respecto a este problema? Mi aplicación realmente lee los datos en un archivo, pero para las pruebas utilicé datos simulados de una tienda en memoria.

Algún consejo?

Answer 1

¿Cómo son sus pruebas?

¿Está seguro de que está escribiendo pruebas unitarias y no pruebas de nivel superior de componentes múltiples de su código? Una prueba de unidad pura solo debe llamar a un único método, y es de esperar que ese método tenga llamadas limitadas a otros métodos (posiblemente a través del mocking).

Al enfocarse en la unidad más pequeña posible, puede escribir código para probar casos de borde específicos. Mientras que, si está probando en un nivel superior, a menudo tendrá que escribir todos los tipos de permutaciones de edge-cases. Una vez que tenga cubiertas todas las unidades más pequeñas, puede escribir algunas pruebas de integración de nivel superior para asegurarse de que todas esas unidades estén ensambladas correctamente.

Por ejemplo, si tuviera una aplicación que lee en un archivo CSV de cotizaciones de bolsa y los promedios de todas las citas para un día determinado, que iba a escribir varias pruebas:

• Las pruebas unitarias de todo el CVS análisis
• las pruebas unitarias alrededor de la fecha de agrupación
• las pruebas unitarias en torno al promedio
• las pruebas unitarias alrededor de la pantalla de la respuesta
• y un pequeño número de pruebas de integración que podrían tomar una muy pequeño archivo CVS y páselo a través de todo el proceso.

me disculpo si estoy haciendo suposiciones acerca de las pruebas unitarias, pero desde mi experiencia, considero que a menudo lo que se llama unidad de pruebas no son pruebas de unidad verdadera y más bien las pruebas de integración (o lo que usted prefiere llamarlos, por ejemplo, pruebas funcionales, etc.). Personalmente soy muy culpable de escribir pruebas que eran demasiado amplias, y cada vez que escribo pruebas tengo que obligarme a recordar probar realmente una unidad a la vez.

Answer 2

¿No pudo crear programáticamente un subconjunto de elementos de un conjunto de datos controlado de datos de producción real? Eso es lo que hacemos, y si de alguna manera el modelo de datos ha cambiado, tenemos algunos scripts que actualizan esos datos reales al nuevo modelo antes de usarlo en las pruebas.

Answer 3

El método es grande. Es horrible administrar y hace que el conjunto de pruebas sea masivo.

Tengo un programa separado para generar los datos de prueba. Los datos de prueba generados se almacenan en el disco, la versión está controlada y están disponibles/usados ​​en pruebas unitarias. El tamaño/complejidad de este programa (por ejemplo, tiene su propia IU) no afecta el tamaño/complejidad de las pruebas de la unidad.

Esta es una solución para "es complicado generar los datos" (pero no lo recomendaría para generar gigabytes de datos de prueba, que podrían generarse mejor sobre la marcha).

Además, estoy haciendo esto para pruebas de integración (no pruebas unitarias).

Answer 4

Me gustaría recomendar xUnit Test Patterns: Refactoring Test Code por Gerard Meszaros.

Este caso se asemeja a la General Fixture smell:

posible Solución Tenemos que pasar a un soporte mínimo para hacer frente a este problema. Esto se puede hacer mejor utilizando un accesorio nuevo para cada prueba. Si debemos usar un dispositivo compartido, deberíamos considerar la aplicación de la refactorización Hacer recurso único para crear un espacio de trabajo de base de datos virtual para cada prueba. (Tenga en cuenta que el cambio a un accesorio compartido inmutable (consulte el accesorio compartido) no aborda completamente el núcleo de este problema, ya que no nos ayuda a determinar qué partes del accesorio se necesitan para cada prueba, solo las partes que se modifican están identificadas !)

Answer 5

¿Cuántas situaciones de prueba son compatibles con este conjunto de datos de prueba?

Idealmente, los datos de prueba se deben separar para que haya conjuntos de datos de prueba separados para cada escenario. De lo contrario, los escenarios de prueba dependen indirectamente el uno del otro, lo cual es malo de todos modos.

En otras palabras, tener varios escenarios que comparten el mismo conjunto de datos crea la posibilidad de que al modificar el conjunto de datos compartidos para un escenario inadvertidamente los datos sean incompatibles con otro escenario.

Answer 6

Si su pregunta está relacionada con la generación de un conjunto más grande de datos de prueba, puede hacer uso de alguna biblioteca como NBuilder. Hemos utilizado NBuilder para generar un gran conjunto de datos de prueba. Ofrece una interfaz muy fluida y es muy fácil de usar. Puede encontrar una pequeña demostración del mismo here.