Hay varios escalones de tests. El approach de Damian sugiere Unit Tests y me parece que es a lo que te referis.
A la definicion de test unitario, es un a fraccion de codigo que verifica o corrobora otra fraccion de codigo. Lo mas importante de los tests unitarios es que estas testeando que un codigo hace lo que *vos programador *piensa que hace, sin importar si esta bien en el disenio o no. Por eso en muchos lados ( y creo razon por la que surgio el movimiento TDD) es que estos tests funcionan como una especificacion del codigo que queres escribir. Lo ideal es que el test lo escriba la persona que va a escribir el codigo, pero no es necesario que sea asi. Damian menciona que reduce el tiempo de debugging, y eso es importante porque aproximadamente el 50% del tiempo efectivo del trabajo de un programador se orienta a hacer debugging o corregir errores. Porque reduce el tiempo de debugging? porque cuando algo funcione mal, los tests te van a ayudar a encontrarlo diciendote lo que el codigo SI hace, lo que hace mucho mas facil encontrar el error. Tiene muchas otras ventajas, pero para que quede claro algo, no te hagas la idea de que hacer tests implica mas trabajo. Al contrario, hacer tests es para reducir el trabajo. La moraleja: si queres laburar menos, hace tests :). Es un poco incomodo a veces aplicar TDD especialmente para un principiante, pero de seguro test unitarios es VITAL para reducir el tiempo de debugging Te cuento algo que me paso a mi en la facultad para un trabajo practico. Quede solo haciendo un proyecto de Algoritmos, y tenia un grupo de 3 personas al lado haciendo el mismo tp que yo. Cada vez que agregaba un metodo o algo, lo iba testeando con codigo(muy sencillo). Era (y soy) novato en C++ entonces cometia errores seguido, pero cada vez que algo funcionaba bien , podia quedarme tranquilo de que andaba * bastante* bien. El grupo de al lado escribio el codigo entero del tp primero (sin ni siquiera compilar). Se pasaron toda la tarde arreglando las cosas. Cuando algo se rompia, no sabian si era eso,el metodo auxiliar, algo interno. Se pasaban un monton de tiempo arreglando el codigo. Por mi lado, tarde mucho mas en terminar la aplicacion que ellos esa misma tarde, pero cuando escribi las ultimas lineas de codigo la aplicacion funcionaba bien y pasaba todos los tests. Ellos se tomaron dias en terminar de arreglar lo que habian hecho. Te digo esto con total humildad,no soy un dios programador, simplemente segui una buena practica que me dio excelentes resultados. Te cuento esto porque mientras mas empujes los tests para adelante, mas esfuerzo te va a tomar (y mas lo vas a evitar). Cuanto antes los pongas, menos tiempo vas a perder arreglando la aplicacion, y vas a tenerle mas confianza. El 19 de abril de 2010 14:57, [email protected] <[email protected]>escribió: > On 19/04/2010 10:16, Nestor Rodriguez wrote: > > Que tal amigos de RoR!! > > Yo comencé con RoR, pero sin usar los test o las pruebas, me parecían > complicados, pero cada ves que leo veo que todos hablan de eso y ya me esta > preocupando jeje. > Alguien me pudiera dar un manual, un enlace o explicarme para que realmente > sirven, se que es para realizar test y pruebas (como sus nombres lo dicen) > pero yo pude hacer dos proyectos, funcionando y no necesite usarlos. Pero ya > que lo leo ves tras ves, siento que me estoy perdiendo de algo... > > Si pudieran darme un resumen o algo para empezar a ver este tema, porque > ya le tengo miedo. > > Desde ya gracias > Nestor Rodriguez > > > Yo de test no tengo mucha idea mas de lo que lei, y un poco de unit test > que hice pero por ahi te sirve: > > Entonces, como experiencia propia, me paso algo muy similar. Con mi > compañero de trabajo empezamos a desarrollar una app que no teniamos muy en > claro cual iba a ser el futuro, que iba a tener y todo muy que se va > generando en el camino. Asi que empesamos a desarrollar directamente (ya que > somos novatos y veiamos los test como mucho laburo extra aparte de lo que ya > teniamos). Pero igual no le perdi el ojo a lo que era y para que sirve: Como > te dijo Damian, es basicamente para asegurarte de que tu aplicacion hace lo > que te pidieron, lo que queres y que ante eventuales cambios siga haciendo > lo que dijiste que iba a hacer, y todo eso sin tener que levantar la > aplicacion e ir haciendo click de un lado para el otro tratando de romperlo. > > > Aparte, provando la aplicacion caes aveces en el riesgo de que VOS sos el > creador.. asi que sabes como debe funcionar, los usuarios siempre encuentran > alguna manera de rompertelo, por eso tambien es aconsejable que los test los > escriba otro. > > En mi app sigue sin haber test xD pero realmente crecio bastante y seguimos > agregando; y actualmente nos da algo de "miedo" lanzar las nuevas versiones > porque probando uno nunca esta muy seguro de que anda, uno es humano, se > puede olvidar de probar ciertas cosas. Mas todavia cuando esas cosas son de > versiones viejas, y uno asume de que funcionan bien. Por eso es que hacer > test, va a ser lo proximo en nuestra lista de prioridades. > > _______________________________________________ > 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
