Python / Desarrollo impulsado por testeos

Bienvenidos sean a este post, hoy hablaremos sobre una metodologia de trabajo con test.

Cuando hablamos de la metodologia de Desarrollo impulsado por testeos tambien conocida como TDD (por sus siglas en ingles) nos referimos a una forma de trabajar que se basa en la repeticion continua de un ciclo de desarrollo muy corto, esto fue redescubierto por Kent Beck y se trabaja de la siguiente forma.

El desarrollador primero escribe un test y lo ejecuta, este se supone que chequea una caracteristica que todavia no es parte del sistema, puede ser una nueva caracteristica que deseamos agregar o algo que debe ser removido o enmendado, corriendo el test lo haremos fallar y debido a esto a la fase se la denomina como Roja.

Con nuestro test fallado el desarrollador escribe un minimo de codigo para poder pasarlo, si lo corramos nuevamente y pasa exitosamente esta fase pasa a llamarse Verde, lo usual en esta fase es escribir un codigo que nos permita omitir algo para poder pasar el test, esta tecnica habitualmente llamada «Engaña hasta que lo consigas» y a partir de aqui los tests se enriquecen con diferentes casos extremos y el codigo trampa se reajusta a la logica adecuada, cuando agregamos otros casos de test se lo denomina Triangulacion.

La ultima pieza de este ciclo es cuando el desarrollador se encarga tanto del codigo como de los testeos (por vias separadas) y los refactoriza hasta que esten en el estado deseado, esta fase es llamada Refactor, para ir finalizando con este ciclo podemos decir que el mantra para TDD es «Rojo-Verde-Refactor».

Si bien puede resultar extraño que se piense en tests antes de escribir el codigo, una vez que cambias tu forma de pensar y trabajas con este pensamiento en algun momento magico sucede y veras como mejora la calidad de tus codigos, hasta ahora siempre que escribimos primero el codigo y luego el tests debiamos concentrar no solamente en que hace el codigo sino tambien en como lo hace pero si escribimos los tests primero solo debemos concentrarnos en que hace el codigo, cuando escribamos el codigo ahi nos enfocaremos en como trabaja el codigo para cumplir el que de los tests antes escritos, esto nos permite trabajar los partes de que y como a traves de momentos separados, enumeremos algunos beneficios de trabajar asi:

• Puedes refactorizar con mayor confianza, porque los test se interrumpiran con los errores y el refactor de la arquitectura se beneficiara con test que actua como un guardian
• El codigo sera mas legible, esto es algo muy importante hoy debido a que es mas una actividad social y todo desarrollador pierde mas tiempo leyendo el codigo que desarrollando
• El codigo no estara tan acoplado y sera mas facil de probar y mantener, como escribis primero los tests te fuerza a pensar mas profundamente en la estructura de tu codigo
• Tendras un mejor conocimiento de los requerimientos del negocio, si careces de informacion para la comprension de los requisitos trabajar de esta forma sera muy desafiante y este actuara como un centinela para ti
• Con todas las unidades testeadas nos facilita la depuracion del codigo, tests pequeños proveen documentacion alternativa, cinco lineas de python en un test simple son muy dificiles de malinterpretar
• Mayor velocidad, es mucho mas rapido escribir un test y luego el codigo que escribir el codigo y luego estar depurandolo, dado que primero hacer el TDD y luego el codigo nos hara mas propensos a tener un codigo con menor cantidad de bugs (errores) y por ende menor tiempo de depuracion luego

Pero esto no es perfecto porque tenemos las siguientes deficiencias:

• Toda la empresa debe creer en esto, de lo contrario tendras que estar constantemente convenciendo a tu jefe cada vez que lo intentas, en general esta metodologia no es para obtener resultados a corto plazo sino a largo plazo, cuesta pero cuando se implementa correctamente se obtienen muy buenos resultados
• Si no entiendes los requerimientos del negocio esto se reflejara en los tests y por ende en lo codigos tambien, esto viene aparejado con el cuarto punto de los beneficios, en caso de fallar nos afectara todo el proceso pero hablando la gente se entiende y podras mejorar los tests y el resto
• Los tests mal escritos son dificiles de mantener, si hacemos un abuso de los mocks o muchos supuestos puede derivar en un test ilegible y por ende en un test dificil de mantener pero con practica esto se puede ajustar y lograr un test acorde a nuestras necesidades y de facil implementacion

Como todo en la vida es siempre probar y ver como trabaja, en caso de necesitar mas informacion es recomendable buscar mas bibliografia y un libro recomendable es Test-Driven Development by Example por Addison Wesley del año 2002.

En resumen, hoy hemos hablado sobre una metodologia de trabajo, en este caso sobre TDD tambien conocido como Desarrollo impulsado por testeos, hemos hablado de como es su enfoque desde una forma muy basica, hemos visto cuales son los beneficios que nos brinda y las contras que genera tambien, espero les haya sido de utilidad sigueme en tumblr, Twitter o Facebook para recibir una notificacion cada vez que subo un nuevo post en este blog, nos vemos en el proximo post.