"Pruebas unitarias" un informe

Question

¿Cómo podría "probar la unidad" un informe creado por algún motor de informes como Crystal Reports o SQL Server Reporting Services?

Answer 1

El problema con los informes es similar al problema con las GUI. Si el informe/GUI tiene gran cantidad de información (fuera de lugar) va a dificultar las pruebas. La solución, entonces, es

• Separated Presentation: presentación separada de los contenidos (reglas de acceso a datos// Negocios). En el contexto actual, significa que crea algún tipo de clase ViewModel que refleja el contenido del informe final (por ejemplo, si tiene detalles de pedidos y líneas de pedido en su informe, esta clase debe tener propiedades para los detalles y una lista de líneas). objetos de elemento). ViewModel es infinitamente más simple de probar. La última milla, la aplicación de la presentación al contenido debe ser relativamente trivial (interfaz de usuario delgada).
  p. Ej. si usa xslt para representar sus informes, puede probar los datos xml usando herramientas como XmlUnit o string compare. Puede confiar razonablemente en las transformaciones xsl en el xml de datos para el informe final ... También cualquier error aquí sería trivial de arreglar.
• Sin embargo, si utiliza proveedores de terceros como Crystal Reports, no tiene control/acceso para enganchar la generación de informes.En tales casos, lo mejor que puede hacer es generar archivos de resultados representativos/esperados (por ejemplo, archivos PDF) llamados archivos dorados. Use esto como un recurso de solo lectura en sus pruebas para comparar el resultado real. Sin embargo, este enfoque es muy frágil ... en el sentido de que cualquier cambio sustancial en el código de generación de informes podría volver incorrectos todos los archivos Golden anteriores. Entonces tendrían que ser regenerados. Si la relación entre costo y beneficio de la automatización es demasiado alta, diría Go manual con planes de prueba de doc de la vieja escuela.

Answer 2

Lo mejor que puedo pensar es en comparar los resultados con un resultado esperado.

Quizás se pueda agregar algo de inteligencia, pero no es tan fácil probar estos bloques grandes.

Answer 3

Estoy de acuerdo con Gamecat.

Genere el informe a partir de datos fijos (constantes) y compárelo con el resultado esperado para esos datos.

Después de que usted puede ser capaz de utilizar pruebas sencillas como diff (comprobando si los archivos son idénticos)

Answer 4

Para la prueba de nuestro propio producto de información basado en Java, i-net Clear Reports, corremos toda una serie de informes de pruebas una vez , exportándolos a varios formatos de exportación, asegúrese de que el resultado sea el deseado, y luego haga que estos mismos informes se ejecuten diariamente, comparando los resultados con los datos originales. Cualquier diferencia se muestra como fallas de prueba.

Nos ha funcionado bastante bien. La desventaja de esto es cualquier diferencia menor que podría no hacer ninguna diferencia aparecer como fallas de prueba hasta que se restablezcan los datos de la prueba.

Nota al margen: esto no es exactamente una prueba unitaria sino más bien una prueba de aceptación. Pero no veo cómo podría realmente "probar la unidad" un informe completo.

Answer 5

Mi idea actual es la de crear pruebas en dos niveles:

• Las pruebas unitarias: Estructura del informe que permitan la comprobación usando algunas ideas para probar una interfaz de usuario, como Vista Humble. El informe en sí será tan tonto como sea posible. Debe consistir principalmente en enlaces de campo simples. Los elementos/objetos de datos que actúan como fuente de estas vinculaciones pueden luego probarse en unidades.

• Pruebas de aceptación: genere algunos ejemplos de informes. Verifíquelos con la mano primero. Luego configure una prueba automatizada que haga una comparación usando diff.