On Sat, Sep 13, 2008 at 1:56 PM, Andres Valloud <[EMAIL PROTECTED]>wrote:
> > Guillermo, > > >> Por lo tanto, > >> como apuntarle con el dedo al programador? Con tests, no? Pero estos > >> se hacen despues de ejecutada la accion de programar y antes de que > >> tomen efecto permanente. > > > > En XP se hacen antes de programar. Y CMMI y RUP se estàn modificando para > > que digan lo mismo... > > No estamos hablando de lo mismo. Los tests de XP son una > especificacion de lo que uno tiene que programar. Los tests de los > que hablo con test que verifican como esta implementado lo que pasa > los tests estos que decis. Claramente, solo se pueden correr despues > de programar. En XP existen los test funcionales y los test unitarios. Todos se hacen antes de programar y se ejecutan de manera automatizada. Se jecutan incluso antes de programar. La idea es que fallen antes de que la funcionalidad estè implementada. El problema obviamente es que falla la compilaciòn en vez de fallar los tests, pero desde el punto de vista de XP lo que falla son los tests. La idea es que si el test no fallaba antes de programar, entonces còmo saves que efectivamente la prueba que estàs haciendo realmente prueba algo. La gente que es fanàtica de los tests dice que hay que modificar el còdigo, introduciendo defectos a propòsito para ver si los tests los detectan o no. Esto obviamente viene de fìsicos experimentales màs que de programadores, pero no dejan de estar en elo correcto. El problema es que en mundo del software la mayor parte de los problemas son problemas de organizaciòn (còmo organizo el còdigo para que se entienda, como logro rastreabilidad entre los requerimientos y el còdigo, etc.) de modo que es muy comùn que un defecto introducido para probar un test luego sea imposible de eliminar del sistema ya que con la magia del copy y paste el defecto se reproduce ràpidamente. Una soluciòn serìa utilizar CPD (copy and paste detector) lo que funciona bastante bien. Otra es hacer code review antes de cada check-in, para asegurarse que el còdigo es razonable... Esto es imprescindible... > > > >> Esto me parece incorrecto porque, a > >> priori, no se pueden conocer todas las decisiones que los > >> programadores puedan tomar o decidir tomar, y por lo tanto tampoco se > >> puede evaluar su utilidad de antemano. > > > > ¿Y eso tiene algo que ver con las pruebas automatizadas? > > Si, lo que dije arriba. En realidad las pruebas no son para evitar decisiones de los programadores, sino que son especificaciones a cumplir. Si las especificaciones estàn bien hechas debieran ser concisas y suficientes para determinar que el programa nunca las pase, a no ser que el programador sea inteligente y escriba sòlo el còdigo necesario. Hay proyectos donde los programadores escriben una cantidad de còdigo inùtil, algo asì como el 80% es còdigo inùtil... Los tests a esta gente les dan direcciòn, en el sentido de que no pueden mezclar todo con todo porque entonces no pasan los tests. > > > Andres. > > > > -- Saludos cordiales, Guillermo Schwarz Sun Certified Enterprise Architect --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] http://www.clubSmalltalk.org -~----------~----~----~----~------~----~------~--~---
