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 B. [mailto:[email protected]]
Enviado el: jueves, 05 de abril de 2007 11:27
Para: [email protected]; 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 [email protected] wrote:
2- Carga de datos requeridos por el testo.
1- Base de datos vacia
que he leido entiendo a las fixtures como una mini base de datos de la
2- Meto fixtures (por ejemplo 2 clientes)
las estamos orientando mal.
Ror-es mailing list
[email protected]
http://lists.simplelogica.net/mailman/listinfo/ror-es
–
Fernando B.
blog > http://www.inwebwetrust.net
).