Estrategias para manejar los datos de prueba

Voy a intentar recopilar las distintas formas que he usado para manejar los datos de prueba en distintos desarrollos (y algunas veces también para las entregas parciales de demos de un producto) y compararlas desde las experiencias que tuve.

La hipótesis: “la base de datos va madurando a lo largo de las iteraciones del desarrollo”, esto en contraposición a hacer primero una base de datos y luego un desarrollo guiado por la base de datos.

1. Simplemente una base de datos

Esta es la más básica, creamos la base de datos de nuestra aplicación y la vamos llenando de datos manualmente así como modificando su estructura, si trabajamos en equipo la tenemos en un servidor y todos modificamos la base de datos. Esto quizás sea mas bien una falta de estrategia o “anti-estrategia”.

Desventajas:

• Cuando alguien hace una modificación impacta en la db en línea que usa el resto del equipo, quienes posiblemente aún no tengan las actualizaciones de código correspondiente.
• Si se quiere deshacer una modificación, se debe considerar como otro cambio pues que la db ya fue modificada.
• Van quedando datos obsoletos a medida que se refactoriza nuestra aplicación, práctica necesaria (por no decir obligatoria) en las metodologías ágiles.
• La aplicación es mono-db.

2. Scripts

Tenemos una batería de scripts que crean la estructura de la db e insertan los datos de prueba. Una variante de esto es tener la estructura de tablas en script y los datos en xml con un proceso que los inserte.

Ventajas:

• Permite tener un control de cambios al tener versionados los scripts (o si hacemos scripts incrementales).
• Permite que cada desarrollador trabaje con db locales (y no es necesaria una db en línea compartida)

Desventajas:

• No se cuenta con las mismas validaciones de datos que en la aplicación, por lo que con los cambios de validaciones también pueden quedar datos obsoletos como en la estrategia anterior.
• Los scripts dependen del repositorio donde guardemos los datos.

3. Objetos

Tenemos factorías de objetos (o conjuntos de objetos) los cuales se guardan cada vez que es necesario, usando los mismos componentes de persistencia que la aplicación, pero antes se regenera la estructura de la db de cero utilizando alguna herramienta para esto.

Ventajas:

• Nos permite tener un control de cambios al tener versionado el código fuente.
• Nos permite que cada desarrollador trabaje con db locales.
• Tenemos las mismas validaciones que en nuestra aplicación. No hay datos obsoletos.

Desventajas:

• Es más lento por estar recreando a cada rato la db.

4. Repositorios en memoria

A la opción de “Objetos”, le sumamos usar repositorios en memoria, que guarden nuestros objetos en una lista.

Ventajas:

• Nos permite no tener que definir la estructura de la base de datos hasta avanzado el desarrollo.
• Nos permite tener un control de cambios al tener versionado el código fuente.
• No hay db en línea ni local que tengamos que actualizar.
• Tenemos las mismas validaciones que en nuestra aplicación. No hay datos obsoletos.
• Es mas rápido pues no hay que preparar la base de datos para cada ejecución.

Desventajas:

• Hay que programar estos repositorios en memoria, código que posteriormente va a ser descartado.

Resumen

	Una única DB	Scripts	Scripts y XML	Objetos	Repositorios en memoria
Trabajo en equipo	--	SI	SI	SI	SI
Control de cambios	--	SI	SI	SI	SI
Validación	--	--	--	SI	SI
Performance	alta	media	media	baja	alta
Refactoring	costoso	costoso	costoso	fácil	fácil
Código descartable	ninguno	poco	poco	poco	un poco más