[Ror-es] ¿Qué librerías de testing y alternativas a Test:Unit usáis?

Thu Feb 18 12:01:35 GMT 2010

Yo estoy con Xavier, de echo a la gente a la que enseño Rails les insisto en
que empiecen los test con Test:Unit i factories, el motivo es que, como ha
comentado alguien antes esto es una evolucion, a medida que vas encontranod
problemas o cosas que te gustaria hacer de otra manera vas adaptando nuevas
soluciones, pero es importante saber porque las fixtures son una mierda y
tener suficiente know how para poder usar factories correctamente.

No te preocupes por ir cambiando los tests, no es tan tedioso como pueda
parecer ahora, es una tarea mas del mantenimiento de la aplicacion, a medida
que vas sabiendo mas puedes ir cambiando las fixtures por fatcories, usar
shoulda para testear ciertas cosas etc Per insisto en que para mi es
importante recorrer ese camino, como hemos hecho la mayoria para tener un
conocimiento solido del muno del testing.

mis 2 cent.

El 18 de febrero de 2010 12:41, Pablo Alonso García <
> escribió:

> Hola,
>
> No esperaba semejante aluvión de respuestas de semejantes cracks! Lo cierto
> es que es mi primer proyecto a nivel profesional... No obstante, acabo de
> terminar un máster en Oviedo (en el que por cierto me dió clase Manuel) y mi
> proyecto fue una pequeña red social en RoR. Fue una buena toma de contacto.
>
> Ahí me encontré con el problema de la mantenibilidad de las fixtures.
> Utilicé Single Table Inheritance, tenía bastante relaciones N:M... Definir
> los casos de prueba mediante fixtures era un auténtico infierno. Muchas
> veces, definir los casos de pruebas era tan tedioso que pasaba del TDD y
> codificaba primero... (error!)
>
> Y bueno, ahora lógicamente quiero subsanar esos problemillas y, por qué no,
> introducirme en el mundo del BDD. Pero de repente se juntan mil cosas: que
> sí mocks, stubs, doubles, BDD, fixture replacement, etc... y uno se ve un
> poco desbordado.
>
> Por otro lado, voy a trabajar con otra persona a quien tengo que enseñar
> Ruby/Rails de cero, y si ya de por sí ambos tienen "florituras" tampoco le
> puedo saturar con mas de lo necesario. Los fixtures son bastante resultones
> para introducirse en el mundo del TDD. Y tampoco puedo demorar mucho más la
> decisión que esto tiene arrancar!
>
> Creo que voy a profundizar en el fixture replacement para antiparme a
> posibles problemillas... y el resto igual puedo decantarme por RSpec que ya
> integra un vocabulario más BDD y mocking/stubing... Si no lo veo claro,
> tendré que tirar por el estandar "de facto"...
>
> Me encantaría ir a la charla de Madrid, aunque si es entre semana va a
> estar complicado, ya que vivo en Gijón.
>
> Gracias mil!
>
> Saludos,
>
> El 18 de febrero de 2010 11:25, Roberto M. Oliva escribió:
>
> Xavier Noria wrote:
>> > Mi recomendacion es que empieces con lo que viene en Rails: Test::Unit
>> > y fixtures.
>> >
>> > Es tu primer proyecto, no te lies aqui. La gente usa otras cosas
>> > cuando ya ha pasado por esto, y como veras van en distintas
>> > direcciones, no hay solucion unica. Tambien es importante que alguna
>> > gente pasa por aqui y NO cambia. Yo mismo uso Test::Unit y a mucho
>> > estirar shoulda.
>> >
>> > No te compliques en tu primer proyecto en este tema. La mayor
>> > documentacion y soporte builtin los vas a tener para Test::Unit y
>> > fixtures, es lo que Rails soporta y mantiene de fabrica.
>> > _______________________________________________
>> > Proudly free of Ruby Forum crossposting since 01/07/2009
>> > Ror-es mailing list
>> > 
>> > 
>> >
>> >
>> >
>> Hola!
>>
>> Estoy totalmente de acuerdo contigo en utilizar Test::Unit en un
>> principio. En realidad, no se necesita más. Todas las otras librerías
>> son mejoras o interpretaciones de cómo hacer testeos, pero un buen uso
>> de Test::Unit es suficiente para realizar testeos unitarios
>> satisfactorios.
>> En lo que no estoy totalmente de acuerdo es en el uso de fixtures.
>> Nosotros empezamos a utilizarlas en un proyecto y al final las
>> deshechamos por un motivo muy simple: Los datos de base de un testeo
>> deben ser aislados a dicho testeo.
>> Me explico: Para realizar un testeo se debe de partir de unos datos base
>> para comprobar que el objeto de nuestro testeo se comporta como
>> esperamos en base a esos datos. El problema de las fixtures es que se
>> comparten para todos los testeos de la aplicación haciendo que, a la
>> larga, la base inicial de los datos se vaya modificando para adaptarla a
>> nuevos testeos según se van añadiendo. Haciendo que el manteniemiento de
>> las fixtures sea un infierno.
>> No se si me he explicado. También es cierto que nosotros nos encontramos
>> con este problema en la version 1.2.6 de Rails y que posiblemente esto
>> lo hayan mejorado, pero se nos quitaron totalmente las ganas de utilizar
>> fixtures y pasamos a utilizar un sistema de factorias de objetos propio.
>> (del tipo de Machinist o Factory-girl).
>>
>> Nosotros ahora utilizamos para los nuevos proyectos: rspec, cucumbre,
>> factory-girl. Pero los antiguos los seguimos manteniendo con Test::Unit
>> y bastante contentos. Utilizar testeos ayuda a dormir tranquilo y a
>> mejorar la aplicación más rápidamente.
>>
>> Un saludo
>> Roberto M. Oliva
>>
>> _______________________________________________
>> Proudly free of Ruby Forum crossposting since 01/07/2009
>> Ror-es mailing list
>> 
>> 
>>
>
>
>
> --
> Pablo Alonso García
> 
> http://alonsogarciapablo.com
>
>
>
> _______________________________________________
> Proudly free of Ruby Forum crossposting since 01/07/2009
> Ror-es mailing list
> 
> 
>
>

-- 
Emili Parreño - www.eparreno.com
Ruby/Rails Trainer & Consultant - www.prorubyteam.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.simplelogica.net/pipermail/ror-es/attachments/20100218/034c68c8/attachment-0001.htm 