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 >
Esto es válido si reemplazás el acceso a base de datos por mocks, yo no hablo de eso, yo hablo de reducir el acceso a lo mínimo necesario, y crear tests específicos para lo que requiera base de datos realmente. > 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). > Lo respondí en el mail anterior esto.. si hacés las cosas bien tenés más ambientes y en particular staging que es un émulo de producción. > > 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. > A nivel cloud puede ser, pero es una infraestructura que no vale la pena en la mayoría de los proyectos, y menos proyectos que no son pagos. :) -- Francisco Tufró [email protected] http://www.franciscotufro.com.ar http://quov.is http://www.dias-felices.com.ar http://www.myspace.com/diasfelices
_______________________________________________ Ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
