Lo que a mi me ha dado más resultados para mejorar la velocidad de los tests que usan DB fue aislar todo el acceso a la base de datos detrás de una capa que funciona como Repositorio de datos. En los tests, en vez de utilizar esta capa se usa una implementación Fake en memoria que es mucho más rápida que la versión real. El problema es que de esta manera se pueden enmascarar errores en la capa de acceso a la db, pero esto se puede mitigar escribiendo tests sólo para esta capa, que serían los únicos que acceden realmente a la DB. También se pueden preparar los tests de manera que el repositorio que usan sea configurable y utilizar el real o el fake según la situación (por ejemplo el fake normalmente y el real cuando vamos a hacer commit al repositorio). El enfoque está mejor contado acá: http://xunitpatterns.com/Faster%20Tests%20Without%20Shared%20Fixtures.html Saludos!
--- El vie, 6/18/10, Francisco Tufró <[email protected]> escribió: De: Francisco Tufró <[email protected]> Asunto: Re: [RubyArg] fast_context A: "Grupo Ruby Argentina" <[email protected]> Fecha: viernes, 18 de junio de 2010, 02:57 pm 2010/6/18 Damian Janowski <[email protected]> 2010/6/18 Francisco Tufró <[email protected]>: > @sromano: Me interesó como te comenté el approach de no usar el layer de > base de datos salvo cuando es realmente necesesario. Podrías pasar el post > que comentaste sobre reducción de tiempo de testing? Desde mi humilde experiencia te recomendaría que no vayas por ese lado. Es muy engorroso y lo único que hacés es bajar la calidad de tus tests (hay gente que cree que testear de esta manera es más 'correcto' – esa discusión la podemos tener en un hilo aparte). Si lo que buscás es reducir el tiempo que tarda en correr tu suite, te recomiendo otros caminos, como usar una base de datos en memoria (sqlite te deja), o incluso armar un ambiente distribuido para correr tests en paralelo. Hubo una charla hace poco en GoRuCo justamente sobre estas opciones. Podés ver los slides en http://github.com/ngauthier/Grease-Your-Suite Te agradezco el comentario. De todas formas no le tengo miedo a lo 'engorroso'. 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. La base de datos en memoria ya la estoy usando, y no generó una reducción de tiempo considerable. 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. Gracias! -- Francisco Tufró [email protected] http://www.franciscotufro.com.ar http://quov.is http://www.dias-felices.com.ar http://www.myspace.com/diasfelices -----Adjunto en línea a continuación----- _______________________________________________ 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
