2008/12/3 Nicolás Sanguinetti <[EMAIL PROTECTED]> > > Hasta hace un tiempo, era un firme creyente en limitar los tests al > caso mas especifico posible, stubbear todo, y asegurarme de que todos > los tests fuesen unitaros. > > Hoy en dia, hago todo lo contrario. Estoy escribiendo *solo* tests de > aceptación (usando Cucumber), y cuando necesito testear algun edge > case, o tengo que modelar algún api "no convencional", bajo a escribir > units.
A mi me pasa justamente que me cuesta muchísimo pensar "de arriba hacia abajo", necesito siempre comenzar por los units (y, digamos, siempre queda poco tiempo para integración y aceptación). Recién cuando voy conociendo la funcionalidad es que "me sale" el diseño de la "interacción"... > > > Ojo, los tests son lentos. Esa es una contra grande a ir contra toda > al aplicación en lugar de testear en aislación una clase dada (además, > ruby es lento! >:-)), pero a) me dicen si anda o no exactamente lo que > el cliente quiere (si los stories de cucumber son buenos) y b) no > pierdo horas manteniendo tests. > > (b) es un problema grande. Mañana refactorizas un método de un modelo > y pasa una de dos cosas: > > 1) Cambiás todos los controller tests que usan dicho modelo > (engorroso, aburrido, perdida de tiempo que le estás cobrando a tus > clientes sin darle ningún beneficio a ellos) > > 2) Te olvidás, y todos los tests siguen pasando, por más que tu > controller se rompe, y el cliente te llama a las 3am para putearte > porque justo hizo una demo a un potencial inversionista =P (no, no me > pasó, pero podría) > > > En definitiva, escribir tests a lo más alto nivel posible, y, a medida > que se hace necesario por edge cases, ir bajando de nivel hasta units. Me encantaría :D > > > Y ta, el tema de la lentitud se puede "arreglar" no corriendo toda la > suite de tests todo el tiempo, sino solo los que te importan a vos > mientras estas trabajando, y dejar que un servidor de integracion > continua como Integrity [1] te avise si se rompio algo ;-) Así trabajan en github, por ejemplo (si, si, usan integrity =P) -- Ojo, > esto solo funciona si pusheas cambios seguido. Si sólo pusheas una vez > al final del dia, suerte en pila =) Chivo!! :D > > > -foca -- nachokb > > > [1] Chivo! http://integrityapp.com > > On Wed, Dec 3, 2008 at 12:38 PM, Pedro Visintin > <[EMAIL PROTECTED]> wrote: > > Hola Gente: > > > > Creo que todos estamos de acuerdo que las metodologías no estan 100% > maduras > > y estan evolucionando continuamente. > > > > A medida que avanzamos nos aparecen nuevas preguntas y cuestionamientos > > sobre lo que venimos haciendo y si nos sirve para lo nuevo o si hay forma > > mejor de hacerlo. > > > > Muchas veces caemos en el cliche de tomar lo que dice el libro, pero > siempre > > es lo mejor? > > > > En cuanto a testing hay muchos interrogantes y muchas diferentes formas > de > > encarar las cosas. > > > > Esta charla plantea algunas cosas interesantes para pensar: > > > > http://rubyconf2008.confreaks.com/testing-heresies.html > > > > De ahí sale la pregunta: Con los specs y tests de controllers hago > stubbing? > > > > pros que veo con stubbing: > > el dominio del test lo tengo claro, estoy testeand el controller. > > me fuerza a hacer stubbing de todas los mensaje s que mando a los objetos > lo > > cual queda bien ajustado. > > me delata si tengo acciones mal hechas cuando tengo que hacer mucho > stubbing > > es porque el controller esta haciendo mas de lo que tiene que hacer. > > > > contras que veo con el stubbing: > > si mi diseño del controller no es bueno voy a avanzar muy lento teniendo > que > > hacer miles de stubbings y mocks > > pueden romper el modelo y el spec del controller va a seguir funcionando. > > (aqui un punto interesante, el spec de controller es de integracion?) > > > > pros que veo sin stubbing: > > estoy testeando el modelo tambien > > puedo ahorrar tiempo en el stubbing > > > > contras que veo sin stubbing: > > no queda claro que estoy probando en los specs se mezcla un poco la cosa, > > requiere mas atencion al escribirlos > > acciones complejas en el controller pasan desapercibidas > > > > Seguramente sus puntos de vista seran diferentes y me parecio interesante > > abrir la discusión > > > > Gracias por hacer tan buena esta lista! > > > > Saluti > > > > P > > > > -- > > Pedro Visintin . S o f t w a r e A r c h i t e c t > > http://www.pedrovisintin.com > > > > Ruby On Rails Argentina. http://blogs.onrails.com.ar > > > > Personal page: > > http://www.p-e-t-e-r-p-u-n-k.com.ar > > > > "Todo descontento por aquello que no tenemos parece provenir solamente de > > nuestra falta de gratitud por aquello que tenemos" > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ > Grupo de Usuarios Ruby del Uruguay - http://groups.google.com/group/ruguy > Anular suscripción - [EMAIL PROTECTED] > -~----------~----~----~----~------~----~------~--~--- > >
_______________________________________________ Ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
