Dónde almacenar el resultado esperado de una prueba?

Question

Escribiendo una prueba Espero que el método probado devuelva ciertas salidas. Por lo general, estoy comprobando que para una determinada operación de base de datos obtengo un determinado resultado. Mi práctica ha sido, por lo general, escribir una matriz como un archivo rápido de mapa/propiedades en la prueba en sí. Esta solución es rápida y no es vulnerable a los cambios de tiempo de ejecución de un archivo externo para cargar los resultados esperados.

Una solución es colocar los datos en un archivo fuente java, por lo que inflaré menos la prueba y aún obtendré una prueba comprobada en tiempo de compilación. ¿Qué tal esto?

¿O es loading the exepected results as resources un mejor enfoque? Un archivo .properties no es lo suficientemente bueno ya que puedo tener solo un valor por clave. ¿Es commons-config el camino a seguir?

Preferiría una solución simple donde nombro las propiedades por clave, entonces, para cada entrada, podría tener un valor de propiedad doc-length y numFound (¿suena como los elementos de un nodo xml)?

, ¿cómo ir sobre esto?

Answer 1

Sí, el uso de los recursos para los resultados esperados (y también los datos de configuración) funciona bien y es bastante común.

XML bien puede ser un formato útil para usted - ser jerárquico sin duda puede ayudar (un elemento por método de prueba). Depende de la situación exacta, pero definitivamente es una opción. Alternativamente, JSON puede ser más fácil para usted. ¿Con qué se siente cómodo, en términos de API de serialización?

Answer 2

Dado que menciona que por lo general está probando que una determinada salida vuelve operación DB espera, es posible que desee echar un vistazo a utilizar DBUnit:

// Load expected data from an XML dataset 
    IDataSet expectedDataSet = new FlatXmlDataSetBuilder().build(new File("expectedDataSet.xml")); 
    ITable expectedTable = expectedDataSet.getTable("TABLE_NAME"); 

    // Assert actual database table match expected table 
    Assertion.assertEquals(expectedTable, actualTable); 

DBUnit se encarga de comparar el estado de una tabla después de una operación ha completado y afirma que los datos en la tabla coinciden con un DataSet esperado. El formato más común para la DataSet que se compara el estado real de la tabla con, probablemente está utilizando un XmlDataSet, donde los datos se espera se carga desde un archivo XML, pero hay otras subclases también.

Si ya está haciendo una prueba como esta, entonces parece que ya ha escrito la mayoría de la misma lógica, pero DBUnit puede darle funciones adicionales que aún no ha implementado de manera gratuita.

Answer 3

usted debe recordar sobre el mantenimiento de este tipo de pruebas. Después de escribir varias pruebas de servicios web con el soporte de prueba de Spring-WS, debo admitir que almacenar las solicitudes (configuración de prueba) y las respuestas esperadas en archivos XML externos no fue una buena idea. Cada par de solicitud y respuesta tenía el mismo prefijo que el caso de prueba, por lo que todo estaba automatizado y muy limpio. Pero aún la refactorización y el diagnóstico de fallas en las pruebas se vuelven dolorosas. Después de un tiempo me di cuenta de que incrustar XML en el caso de prueba como String, aunque feo, es mucho más fácil de mantener.

En su caso, supongo que invocará alguna consulta de base de datos y obtendrá una lista de mapas en respuesta. ¿Qué tal escribir algún buen DSL para hacer afirmaciones sobre estas estructuras? En realidad, FEST-Assert es bastante bueno para eso.

Digamos que se prueba la siguiente consulta (Sé que es una simplificación excesiva):

List<Map<String, Object>> rs = db.query("SELECT id, name FROM Users"); 

, entonces puede simplemente escribir:

assertThat(rs).hasSize(1); 
assertThat(rs.get(0)) 
    .hasSize(2) 
    .includes(
    entry("id", 7), 
    entry("name", "John") 
) 
); 

Por supuesto que puede y debe simplificarse aún más para adaptarse tus necesidades mejor. ¿No es más fácil tener un escenario de prueba completo en una pantalla en lugar de saltar de un archivo a otro?

O tal vez deberías probar Fitnesse (parece que ya no estás haciendo pruebas unitarias, entonces el marco de pruebas de aceptación debería estar bien), donde las pruebas se almacenan en documentos tipo wiki, incluyendo tablas?