Muy a menudo en nuestro día a día podemos encontrarnos que el trabajo no esta del todo bien planificado, pero lo normal es conseguir sacar el trabajo y seguir para adelante sin mirar atrás. Ese no es mi caso, me encuentro en un proyecto con una gran envergadura en el que estamos involucrados más de 300 personas, donde el caos reina en cada esquina y en cada linea de codigo, tanto es así que en estos momentos estoy realizando las pruebas unitarías usando una herramienta denominada JUnit de la cual en otro momento explicare alguna cosa.
El problema en este caso es que estos test se estan efectuando sobre los servicios, los cuáles son un nodo de interconexión entre la BBDD y el código Java. A estas alturas del proyecto los servicios deberían ser definitivos y no tocarse, la realidad es muy diferente, los servicios estan en continua evolucion hasta el punto de pasar de un solo @autowired a cinco lo que nos lleva a pasar de dos pruebas a un mínimo de diez.Lo peor de este tema es que los jefes han olvidado que sucede en este tipo de tarea cuando todavía esta viva y es que el resultado que puedes esperar como mucho es de mantenimiento, siempre habrá un servicio que sera modificado y eso es lo que me duele, que siendo yo el unico que realiza esta tarea de mi grupo se me señale con el dedo y me digan que no hay resultados.Por poner un ejemplo, el viernes cuando me fui deje el modulo al 74% , hoy nada más comenzar el día he sincronizado todo el proyecto y ese modulo se encontrarba al 40%. Falta matizar que siempre sincronizo antes de subir nada, me encanta asegurarme de que lo que subo no fastidia a nadie.La solución para este tipo de problemas es fácil, se puede realizar de dos maneras; una sería el posponer la realización de los mismos, pero como esto no puede ser pasamos a la segunda que sería tan básica como que cada programador se ocupara siempre de su test, de esta manera nos ahorraríamos sorpresas inesperadas como la que he tenido esta mañana, todos aprenderíamos y los test se realizarían mucho más exacto.
El problema en este caso es que estos test se estan efectuando sobre los servicios, los cuáles son un nodo de interconexión entre la BBDD y el código Java. A estas alturas del proyecto los servicios deberían ser definitivos y no tocarse, la realidad es muy diferente, los servicios estan en continua evolucion hasta el punto de pasar de un solo @autowired a cinco lo que nos lleva a pasar de dos pruebas a un mínimo de diez.Lo peor de este tema es que los jefes han olvidado que sucede en este tipo de tarea cuando todavía esta viva y es que el resultado que puedes esperar como mucho es de mantenimiento, siempre habrá un servicio que sera modificado y eso es lo que me duele, que siendo yo el unico que realiza esta tarea de mi grupo se me señale con el dedo y me digan que no hay resultados.Por poner un ejemplo, el viernes cuando me fui deje el modulo al 74% , hoy nada más comenzar el día he sincronizado todo el proyecto y ese modulo se encontrarba al 40%. Falta matizar que siempre sincronizo antes de subir nada, me encanta asegurarme de que lo que subo no fastidia a nadie.La solución para este tipo de problemas es fácil, se puede realizar de dos maneras; una sería el posponer la realización de los mismos, pero como esto no puede ser pasamos a la segunda que sería tan básica como que cada programador se ocupara siempre de su test, de esta manera nos ahorraríamos sorpresas inesperadas como la que he tenido esta mañana, todos aprenderíamos y los test se realizarían mucho más exacto.
0 comentarios: (+add yours?)
Publicar un comentario