Tests da para largo (tal vez sea un posible tema para otra reunión) asi que voy a mandar este mail y prometo no responder a sus réplicas (y espero nadie se enoje por ello).
1) @francisco, prometo buscar el post cuando tenga tiempo, no prometo encontrarlo 2) Un test que testea una sóla funcionalidad, es un test de menor calidad? Definitivamente, NO. Creo (y me bancaría cualquiera que haga TDD) que un buen test, testea una sóla cosa. Hacer un gran test tiene los mismos problemas que un gran método/diseño monolítico. Un test que al mismo tiempo chequea base de datos, acceso a disco, 4 métodos, 5 resultados me parece un mal test. 3) No quita que cuando uno no está haciendo TDD, tenga sentido hacer algunos test de integración, pero no muchos. 4) De la experiencia, veo mucho tests que testean más cosas de las que deberían. Lo mismo ocurre con los acceso a bases de datos. Veo muchos tests que "testean" (capaz sin saberlo) accesos a base de datos cuando está lejos del scope que le querían dar al test. Veo mucha gente hacer test de integración y definirlos como unitarios. 5) Hay mucho jugo en este tema, muchos problemas creo que vienen de que ActiveRecord es tan natural para nostros que confundimos algunas cosas. Creo que vale una reunión para charlar. 6) Cloud no viene a resolver los problemas de performance. No patiemos la pelota. 2010/6/18 Damian Janowski <[email protected]> > 2010/6/18 Francisco Tufró <[email protected]>: > > Te agradezco el comentario. > > De todas formas no le tengo miedo a lo 'engorroso'. > > Yo sí. > > > En cuanto a la calidad de los tests no creo que baje, todo depende de > cuán > > vivo seas para darte cuenta de cuándo una interacción en la db puede > afectar > > o no. > > Baja la calidad porque algo que antes estabas testeando, ahora no lo > estás testeando más. Siguiendo con el plan de mockear todo, podrías > mockear, por ejemplo, los accesos a disco. El tema es que cuando haya > un problema con la base de datos, o el disco, probablemente no te > enteres (en tus tests – te vas a enterar con el mail del cliente). > > Fijate los tests que genera automáticamente RSpec, vas a ver que el > valor de esos tests es muy bajo. > > > La base de datos en memoria ya la estoy usando, y no generó una reducción > de > > tiempo considerable. > > Puede ser, lo sugería nomás. > > > Los tests en paralelo tienen un límite, son una mitigación al problema y > no > > una solución, aunque los voy a implementar al menos en integración > continua, > > pero estoy buscando una solución más radical. > > Creo que no entiendo bien. Me parece que cloud computing es una > solución y justamente no tiene límite. Mockear sí tiene límite, porque > a medida que crezca tu suite vas a ir acercándote a los límites del > único procesador que estás usando. > > Correr el build en paralelo me parece bastante radical, pero por lo > menos es un paso en la dirección correcta para el problema. Adoptar > una filosofía de testing de menor calidad me parece que no tiene que > ver con el problema que estarías intentando solucionar. > _______________________________________________ > Ruby mailing list > [email protected] > http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar >
_______________________________________________ Ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
