Roberto M. Oliva

Estamos desarrollando un proyecto en Ruby on Rails de un tamaño que empieza a
ser considerable. Para los testeos (tanto unitarios como funcionales)
estamos utilizando las fixtures y me estan surgiendo una serie de dudas
filosoficas, a ver que opiniones teneis al respecto.

En otros proyectos que he desarrollado (en .NET) he realizado los
testeos siguiendo estos pasos por cada testeo (nada nuevo):

1. Base de datos vacia
2. Carga de datos requeridos por el testo.
3. Ejecucion de la funcionalidad a testear
4. Comprobacion del resultado de la funcionalidad.

La idea es que yo preparo los datos para asegurarme el resultado del
testeo. Con lo que consigo, entre otras cosas: Testeos aislados
(requisito fundamental del TDD) y logica del testeo minima (si hacemos
una logica grande nos puede fallar y eso es lo peor que nos puede
pasar… a no ser que testeemos el testeo ).
Por ejemplo, voy a testear una funcion que me devuelva los clientes que
haya en una tabla:

1. Base de datos vacia
2. Meto dos clientes en la tabla
3. Ejecuto la funcion.
4. Compruebo que me devuelve 2 clientes y que tienen los datos esperados.

Como se ve la comprobacion es minima en cuanto a funcionalidad.
Con esta aproximacion he realizado proyectos basados en TDD con
resultados muy satisfactorios.

Por otro lado, está lo que utiliza Rails que son las fixtures. Por lo
que he leido entiendo a las fixtures como una mini base de datos de la
aplicacion sobre la que hacer testeos. Esto tiene la ventaja de que
facilita mucho la entrada de datos en la base de datos pero complica
muchisimo la comprobacion de los datos ya que los testeos no son
aislados. Esto hace que la comprobacion no presupone nada sobre el
estado inicial de los datos, hay que realizar funcionalidad de testeos
para saber que el resultado requerido es correcto. Siguiendo los
ejemplos anteriores se seguiria un proceso como el siguiente utilizando
fixtures:

1. Base de datos vacias
2. Meto fixtures (por ejemplo 2 clientes)
3. Ejecuto la funcion a testear
4. Consulto el numero de clientes que hay en la base de datos
5. Compruebo que el punto 3 y el punto 4 me devuelven lo mismo.

Hay que hacerlo asi porque nadie me impide, por que lo necesite
para otro testeo, el incluir uno o mas clientes en la lista.

Resumiendo: las fixtures no apoyan el aislamiento
de los testeos, mas bien lo perjudican… eso, o es que las estamos
orientando mal.