El problema es que aunque un test individual tarde sólo 3 o 4 segundos,
es muy fácil en una aplicación mediana tener más de 500 tests,
con lo cual se llega a cerca de media hora de ejecución.
oops! 500 tests es muy poco; yo lo llamaría aplicación pequeña o quizás
no estan hablando de los tests que quedan como subproducto del
trabajo diario y solo una minima cantidad de "tests selectos".
Ahh! y media hora? ehh los corren en carreta? :-)
(es con buena onda... quizás son test que ejecutan en la China jajaja)
Entre 5 y 20 mil tests son en gral resultantes de un desarrollo medio
de dos años (en varios casos he visto bastante mas).
En nuestro caso, nuestro set completo de testing es de casi
5 millones de tests (gran parte no fueron escritos por personas);
por lo general son tests de una a tres operaciones
(aunque hay aprox. 100 test que verifican 30 o mas puntos, por ejm,
de operaciones matematicas y en tests de tecnicas de analisis de video
por comp. vision).
En caso de ejecutar todos los tests, son dos y media horas en
una compu "normal", pero rara vez se ejecutan todos durante
el desarrollo diario (quien dice
que esta corriendo todos los tests gralmente está cerca de una
cafetera o a punto de servirse un cafecito).
En nuestro caso la forma en que se usan los test es dirigida por un
interés de busqueda/confirmación en un rango específico (por ejm:
acabo de romper algo en XXX al hacer YYY?); por lo que
mecanismos de seleccion de los tests antes de correrlos
es lo que motiva a su uso. La seleccion puede ser tan simple como
usando la categorización de los mensajes de testing, como tambien
otros filtros usando reflexión en los metodos (pero son pocos los
casos de filtros mas complejos que por categorias).
En desarrollos de aplicaciones comerciales e industriales que
se mantienen por varios años he visto que el nro de tests
entre 5k y 20k se mantiene estable y que la relacion beneficio/costo
al acompañar los cambios dados en el sistema no es tan alagadora
como para el desarrollo inicial.
En los casos de equipos que no usan baterias de tests o que
los usan parcialmente, la calidad del software y su
estabilidad NO se ve comprometida en la práctica siempre y cuando
sea correcta la relación entre personal experto/principiante
y se promueva el trabajo de a pares
u otra tecnica de educación en producción.
1 saludo
Ale.
Como los tests que usan BD llegan fácilmente a estos tiempos, es una
solución común fakear el acceso a BD.
----- Original Message -----
From: Lorenzo Jorquera
To: Grupo Ruby Argentina
Sent: Friday, June 18, 2010 4:06 PM
Subject: Re: [RubyArg] fast_context
Con el tema de los tiempos de corrida de los tests, de que tiempos están
hablando de bajar? 1hr, 2hr?
Mi imagino una aplicación muy compleja para esos tiempos, creo que no es
necesario testear la aplicacion completa constantemente, separando los tests
en batch puede ir probándose las partes en que se trabaja y sus
dependencias, y en algún momento todo el sistema completo.
No, para que los tests sean útiles tenemos que hablar de tiempos de corrida
de menos de 5 minutos, como mucho. Si los tests tardan una hora se van a
correr muy esporádicamente y por lo tanto no van a ser muy efectivos.
El problema es que aunque un test individual tarde sólo 3 o 4 segundos, es
muy fácil en una aplicación mediana tener más de 500 tests, con lo cual se
llega a cerca de media hora de ejecución. Como los tests que usan BD llegan
fácilmente a estos tiempos, es una solución común fakear el acceso a BD.
_______________________________________________
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
