[Ror-es] A vueltas con las fixtures

[Roberto M. Oliva]

Hola Fernando!

Gracias por tu ladrillo (que no lo es tanto). Nosotros empezamos planteando
las fixtures precisamente porque veia las ventajas que tu comentas. Sobre
todo el que los datos son mas logicos organizados en fixtures que insertados
"a mano".
El problema nos ha surgido cuando ha ido creciendo el numero de modelos en
la aplicación. Ha llegado un momento en que una modificacion en las fixtures
para contemplar las novedades hacia que rompiesen muchos otros testeos tanto
por la logica (que puede ser normal) como por la funcionalidad de los
testeos (esto es lo que mas complica el tema).
Queria contestaciones como la tuya, porque ya tengo algo que investigar:
assert_difference(Model, :count, n)
Y aprovecho para hacerte una pregunta... En los testeos que tu haces, como
los evaluas? Contra valores fijos? Consultas la base de datos para comparar
lo devuelto por la funcionalidad?

Muchas gracias por tu ayuda
Un saludo
Roberto M. Oliva
 

-----Mensaje original-----
De: Fernando Blat [mailto:ferblape at gmail.com] 
Enviado el: jueves, 05 de abril de 2007 11:27
Para: roliva at idecnet.com; La lista sobre Ruby On Rails (rubyonrails.com) en
castellano
Asunto: Re: [Ror-es] A vueltas con las fixtures

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