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
