[Ror-es] A vueltas con las fixtures

[Fernando Blat]

Claro, es que muchas veces el problema es hacer un test lo suficiente
genérico como para que te sirva aunque vayas modificando datos y
fixtures.

Un buen truco es hacer, siempre que se pueda, algo como esto:

obj = Class.find(1)

Y utilizar los atributos de obj para todo, por ejemplo para las urls:

get :edit, :id => obj.id

O para comprobar literales, etc

Es difícil y a pesar de todo los tests son bastante poco genéricos,
pero bueno, mejor eso que llenarlo todo de literales, y que cuando
cambias uno, tienes que cambiarlos todos.

Espero que te sirva. Un saludo!!!

On 4/9/07, Roberto M. Oliva <s918517298 at wanadoo.es> wrote:
> 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
>
> _______________________________________________
> 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