Testeando un CRUD básico con JUnit
Publicado por Alberto (6 intervenciones) el 01/06/2012 20:00:24
Hola a todos,
Es mi primer post en el foro. Ante todo agradeceros vuestra colaboración.
Soy un profesor de informática y he propuesto una práctica sencilla para mis alumnos en la que tienen que diseñar un API que realice un CRUD básico (create, recover, update y delete) de datos en una tabla de una base de datos.
Los métodos del API, de significado obvio (espero) son:
insertar(id:int, dato:String)
borrar(id)
consultar(id): String
modificar(id, String)
=============
Paralelamente, les he pedido que diseñen una suite de Pruebas para esta API con JUnit.
Mi pregunta es la siguiente:
¿Cómo diseñar estas pruebas sin caer en recursividad mutua?... me explico:
Para probar el método "consultar", siguiendo la filosofía de la triple A (AAA, arrange, act, assert) lo que creo que habría que hacer es algo así como:
- (ARRANGE) Insertar un dato arbitrario en la base de datos digamos (1, "DATO").
- (ACT) Llamar a consultar(1) y almacenar el dato en un String llamado "obtenido"
- (ASSERT) assertEquals(obtenido, "DATO")
- (LIMPIAR) Borrar de la base de datos la fila (1, "DATO") para que el test sea inocuo e independiente de los demás test que se realicen.
==============
Lo que no llego a entender es, ¿cómo hacemos la primera y última parte, es decir insertar el dato en la BD y borrarlo al final?
1) ¿Introducimos código JDBC directamente, conexión a la BD, crear un Statement, etc.?
2) ...o bien, ¿utilizamos los métodos insertar y borrar del API que estamos diseñando?
Si optamos por la opción (1) el código se puede complicar mucho y exceder la simplicidad de una prueba unitaria. De hecho, puede ser tan complejo que podríamos necesitar otra prueba para probar que la propia prueba funciona correctamente.
Si optamos por la opción (2) el código es más sencillo, pero la prueba unitaria deja de ser independiente ya que para poder realizar su tarea, necesita confiar en el buen funcionamiento de otros dos métodos del API, que para más INRI necesitarían confiar en el buena funcionamiento del método "consultar" (recursividad mutua).
=================
¿Me podría ilustrar alguien en el método de diseño de este tipo de pruebas? Imagino que tengo un algún tipo de error de concepto en general acerca del diseño de pruebas unitarias.
Muchas gracias de antemano.
Alberto
Es mi primer post en el foro. Ante todo agradeceros vuestra colaboración.
Soy un profesor de informática y he propuesto una práctica sencilla para mis alumnos en la que tienen que diseñar un API que realice un CRUD básico (create, recover, update y delete) de datos en una tabla de una base de datos.
Los métodos del API, de significado obvio (espero) son:
insertar(id:int, dato:String)
borrar(id)
consultar(id): String
modificar(id, String)
=============
Paralelamente, les he pedido que diseñen una suite de Pruebas para esta API con JUnit.
Mi pregunta es la siguiente:
¿Cómo diseñar estas pruebas sin caer en recursividad mutua?... me explico:
Para probar el método "consultar", siguiendo la filosofía de la triple A (AAA, arrange, act, assert) lo que creo que habría que hacer es algo así como:
- (ARRANGE) Insertar un dato arbitrario en la base de datos digamos (1, "DATO").
- (ACT) Llamar a consultar(1) y almacenar el dato en un String llamado "obtenido"
- (ASSERT) assertEquals(obtenido, "DATO")
- (LIMPIAR) Borrar de la base de datos la fila (1, "DATO") para que el test sea inocuo e independiente de los demás test que se realicen.
==============
Lo que no llego a entender es, ¿cómo hacemos la primera y última parte, es decir insertar el dato en la BD y borrarlo al final?
1) ¿Introducimos código JDBC directamente, conexión a la BD, crear un Statement, etc.?
2) ...o bien, ¿utilizamos los métodos insertar y borrar del API que estamos diseñando?
Si optamos por la opción (1) el código se puede complicar mucho y exceder la simplicidad de una prueba unitaria. De hecho, puede ser tan complejo que podríamos necesitar otra prueba para probar que la propia prueba funciona correctamente.
Si optamos por la opción (2) el código es más sencillo, pero la prueba unitaria deja de ser independiente ya que para poder realizar su tarea, necesita confiar en el buen funcionamiento de otros dos métodos del API, que para más INRI necesitarían confiar en el buena funcionamiento del método "consultar" (recursividad mutua).
=================
¿Me podría ilustrar alguien en el método de diseño de este tipo de pruebas? Imagino que tengo un algún tipo de error de concepto en general acerca del diseño de pruebas unitarias.
Muchas gracias de antemano.
Alberto
Valora esta pregunta
0