Luchando contra la última tentación
Ufa; Otro artículo sobre TDD. Si, hay un mucho en la web al respecto de esta técnica de desarrollo. Pero te invito a leer el artículo hasta el final, prometo tratar de no defraudar, al menos te voy a invitar a pensar. Para plantear posturas desde un incio, soy una persona que apoya esta metodología. Requiere maduración y horas. Pero soy un converso. Ahora que sabemos en que vereda estamos , continuo.
Si leiste lo mínimo al respecto sabemos del Mantra:
Es decir empezar por el test; hacer la implementación mínima para lograr que funcione y luego empezar a dejar el mundo más bonito, ó en una primera instancia empezar a hacer un diseño que te deje conforme, con lo que nosotros consideramos “ Por esto Uncle Bob no me odiaría tanto..”
Mi experiencia me ha demostrado un par de cosas:
* Hasta que aprendes a testear te lleva un tiempo.
* Que una vez que aprendes y te dejaron de llamar por que se cayeron las cosas el fin de semana empezás a creer que testear es bueno. ( para vos y tu projimo! el que te llamó odia despertarse por alarmas de gente que no probó las cosas! )
* Si te gusta diseñar , vas a ver como tus modelos van adquiriendo mejores formas, se vuelven más simples y lograste una mejora en la calidad de tus aplicaciones.
Oiga! El punto que pretendes encarar en este artículo todavía no lo tocaste! ahi voy.. ahi voy
Cual tentación ?
Uno tiene conceptos de patrones, leiste aunque sea un par de veces al GOF, y entendes de lo que hablamos de SOLID ( si no ocurrió esto, que estas esperando ? una invitación de Messi ? )
Pero TDD ataca el problema por otro lado, te dice que tenes un problema , que arranques en la parte del testeo y que en función de eso, con lo poco que comprendes (bien) el problema ( al menos entendes que se pretende dilucidar ; este sería el paso 0 de la metodología) , que empieces a implementar una solución para lo que sabes con seguridad, fehacientemente, que debería ocurrir y que luego de ello, empieces a ver como eso que resuelve el problema empiece a ser algo mejor de lo que es ( Colaboradores, responsabilidades, estrategias, etc ). Aquí aparece la tentación.
La tentación de empezar a diseñar “ en el mientras “ estamos queriendo hacer funcionar los test. Todavía no logramos el green , pero ya pretendemos saber donde, con detalles, vamos a poner un Strategy.
Uno esta haciendo la solución para el problema planteado, y uno se tienta en decir “bueno aca hago esto por si esto, y acá hago aquello por si aquello” entonces, a menos que sea una demanda de la funcionalidad, uno empieza a meter manos en un diseño que , creanme por favor en este punto , LEJOS esta de ser el definitivo.
TDD nos invita a una forma de resolver problemas mediante capas de pensamiento, de etapas estamos hablando.
Uno empieza a resolver rudimentariamente la funcionalidad planteada, a propósito en este punto (es muy importante esto), y en un momento nos darnos cuenta que algo que vamos a hacer necesariamente estará encapsulado en un componente cuyo punto de entrada será un simple metodo.
Aquí es donde arrancamos un nuevo test, sabiendo un poco mejor en este punto , de manera más puntual, que escenarios cubrirá el nuevo componente. El anterior test que veníamos haciendo no se resolverá hasta que este nuevo punto no este cubierto. Esto se puede dar iterativamente n veces. Estas son las capas, estas son las Etapas. Pero sepamos que cuando resolvamos el último eslabon de esta cadena, de a poco iremos resolviendo las capas superiores , hasta llegar a tener ese test MAIN, principal, muy cerca de ser solucionadas una buena parte de las ideas que teníamos que resolver , y muchas mas surgirán para poder plantear a la persona que nos solicitó este pequeño desafio.
Es en este punto donde nuestra paciencia tiene su recompensa, y el premio de soportar la tentación tiene su recompensa. En este punto donde nuestra etapa de diseñador comenzará a actuar. Y acá es donde superamos la tentación
Ahora tenemos el Big Picture del problema. Es entonces en este punto en donde podemos jugar con clases Abstractas e interfaces, con resolución de problemas por partes a nivel de diseño y donde veremos focos reales de mejoras, más abarcativos y depurables.
De esto salen dos cosas que deseo destacar:
* TDD es efectivo si entendemos y testeamos el negocio, no la implementación
* El caramelo para los desarrolladores solo lo podremos disfrutar en todo su aspecto si
Sacrificamos nuestra ansiedad de diseñar en función de resolver la foto completa de la funcionalidad a implementar. Luego si, a saborear las ideas.
Estoy plenamente convencido que para comprender TDD mas nutritivamente, para enfocarlo y sacar el máximo jugo de esta metodología (y no hablo solamente del gusto del desarrollador, hablo también de los tiempos y objetivos del proyecto en el que estamos involucrados ), debemos comprender que redactamos nuestros tests para solucionar un tema de negocio y no , y quiero ser explicito con esto, NO debería ser para testear una implementación de esa solución (no esta mal del todo a mi entender si lo consideramos muy necesario ). Comprender esto nos lleva a crear test que solamente se focalizan en escenarios puros y claros dentro del contexto del problema de negocio a desarrollar.
Ser rudimentarios al principio nos proporciona la claridad de ver el codigo y la implementacion de manera explicita de cómo solucionamos tal situación. Esto nos permitirá luego, si la situación lo demanda , claramente ver cuando se requiere Clases Abstractas, Interfaces, Factorias , DI y externalización de configuración ( valioso no ? )
Como corolario , con estas dos premisas cumplidas , obtendremos test robustos, que cambien relativamente poco con cada nuevo feature. TDD no apunta que hagamos muchos test, o test futiles, sobre getters y setters; esta es una visión simplista. La idea principal es simplemente hacer los test necesarios, y que no estemos desarrollando código innecesariamente que ataque escenarios que no fueron pedidos.
Esto que estoy promoviendo, invito a que lo prueben, lo desarrollen con algún kata para algun lenguaje que se sientan cómodos.
Gracias por leer hasta acá ! sean pacientes! y gracias por la brindada!
No hay comentarios:
Publicar un comentario