[Ror-es] A vueltas con las fixtures

Mon Apr 9 12:50:41 GMT 2007

Roberto M. Oliva escribió:
> [...] Queria contestaciones como la tuya, porque ya tengo algo que investigar:
> assert_difference(Model, :count, n)
>   

cuidado, assert_difference no es (a día de hoy) un helper de Rails. 
Nosotros (Blat, otros compañeros en the-cocktail y yo) estamos usándolo 
desde hace mucho tiempo pero en realidad nos lo trajo el "login generator".

> 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 García Samblas
fernando.garcia at the-cocktail.com

The Cocktail
C/ Salamanca 17
28020 Madrid
+34 91 567 06 05