[Ror-es] A vueltas con las fixtures

[Fernando Blat]

Hola Roberto,

la verdad es que yo soy muy joven, y eso unido a las carencias del
plan de estudios de Ingeniero Informático en la Politécnica de
Valencia, han hecho que yo no supiera nada de testing de software
hasta que vi que lo hacía Ruby on Rails.

Así que digamos, que yo he aprendido de testing tomando como base sólo
Ruby on Rails.

Como bien dices, las fixtures son una ayuda de Rails para probar datos
en el entorno de testing, y en cada test tendremos una serie de
fixtures que hayamos definido. Por lo menos yo, le veo más ventajas de
las que tú planteas:

- tener datos ya precargados te ahorra tener que insertarlos cada vez
que quieras realizar una consulta, con lo cuál sólo lo haces una vez
para toda la suite de test y no te repites (DRY famoso) y evitas
errores, etc

- también te permite gestionar los datos de test de forma que puedas
ir incluyendo nuevos datos según avanza el desarrollo del proyecto,
sin tener que modificar luego todas tus funciones. Esto es muy útil
para añadir casos excepcionales, que siempre surgen cuando la
funcionalidad ya está desarrollada.

- (pon aquí tu ventaja).

Y por último, comentar que no resulta tan problemático lo de tener ya
datos para testear la inserción de nuevos datos, por ejemplo
utilizando el helper assert_difference(Model, :count, n) que comprueba
que se hayan insertado n objetos, siendo n un entero tanto positivo
como negativo.

Conclusión, y perdona la piedra de e-mail: que lo de las fixtures no
resulta problemático, sino que puede llegar a ser una ventaja si te
acostumbras a ello.

Y si no te acostumbras, siempre puedes ejecturar un borrado de todos
los objetos del modelo antes de ejecutar el test :)

Un saludo.

On 4/3/07, Roberto M. Oliva <roliva at idecnet.com> wrote:
> Hola a todos!
>
> Estamos desarrollando un proyecto en 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, estan lo que utiliza Rails que son los 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
> 4a- Consulto el numero de clientes que hay en la base de datos
> 4b- Compruebo que el punto 3 y el punto 4a me devuelve lo mismo.
>
> Porque 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 (perdonad por el tocho que os he escrito, pero creo que es
> una teoria interesante para todos) las fixtures no apoyan el aislamiento
> de los testeos, mas bien lo perjudican... eso, o es que las estamos
> orientando mal.
>
> Nos ayudais? Que opinion teneis al respecto?
>
> Muchas gracias!!!
> Roberto M. Oliva
>
>
>
>
> _______________________________________________
> Ror-es mailing list
> Ror-es at lists.simplelogica.net
> http://lists.simplelogica.net/mailman/listinfo/ror-es
>


-- 
Fernando Blat
blog > http://www.inwebwetrust.net