Ayer desde Cartuja .Net hicimos una mesa redonda sobre TDD y la conversación fue muy, pero que muy ilustradora sobre todo para mí.
Aquí mi resumen:
Tras hablar sobre las últimas novedades que habían aparecido en la comunidad .NET tras las presentaciones de #vsconnect y conseguir centrarnos, comenzamos con una explicación sobre qué es TDD muy corta, apenas 30 segundos:
“TDD consiste en que cuando vamos a escribir código, hacer primero un test que falle para el código que queremos escribir, luego el mínimo código que hace que el test se ponga verde, y refactorizar el código que hemos escrito”
Seguimos con la duda que yo tengo sobre ese ciclo, y es que, como ya comenté en otro post, el ciclo es incompleto, falta una primera fase de “pensar” antes incluso de escribir ese primer test.
Es decir, tomar muchas veces papel y lápiz, y dibujar la “arquitectura” que creemos debe ser. Una vez que tenemos separadas las responsabilidades que el sistema debe tener, cogemos una de esas clases y podemos empezar a aplicar TDD sobre esa clase.
Suele ocurrir que al escribir ese test y escribir el código se encuentran dependencias que antes no se habían tenido en cuenta. Es decir, responsabilidades ocultas y suele generar en otra clase que tendremos que mockear para poder seguir avanzando en el ciclo de TDD y avanzando en el nuestro trabajo.
Y aquí llego la primera disputa sobre el concepto de que “la arquitectura emerge“. Tras un rato de dialogo sobre eso, saqué la conclusión de que esa arquitectura que emerge no es la arquitectura del sistema completo, sino la arquitectura del contexto en el que está centrado ese test.
Mi conclusión particular sobre este punto, es que aplicando TDD nos obligamos a pensar en responsabilidades, nos obligamos a seguir el principio de una única responsabilidad y esto, paso a paso, test a test, nos ayuda a averiguar si aquella arquitectura que teníamos en la cabeza, que dibujamos con papel y lápiz en un primer momento es adecuada o no. Como corolario podemos decir que si nos resulta difícil seguir avanzando en ciclos cortos de test-code-refactor, hay que replantearse esa arquitectura ya que parece que esa elección no es adecuada, y eso es bueno, ya que al menos hemos encontrado una forma de no hacerlo.
Tras unas cuantas experiencias que compartimos, buenas y malas, continuamos con la conversación sobre las bonanzas del testing, integración continua, TFS, Team City, programación defensiva, y un largo etcétera. Todos estamos de acuerdo sobre las ventajas, sabemos que es bueno hacer test. Hasta que alguien nos hizo caer en la cuenta de que desde hacía un buen rato no estábamos hablando sobre TDD sino de testing. Así que recondujimos la conversación con el tema de la práctica y la maestría.
Obviamente no es lo mismo empezar a aplicar TDD que llevar tiempo aplicándola. La famosa curva de aprendizaje es en realidad así:
Tenemos un nivel de productividad (verde) y cuando empezamos hay una bajada de productividad importante y empezamos el camino de la práctica hasta que volvemos a alcanzar el mismo nivel de productividad que teníamos antes. En realidad esto pasa con todas las tecnologías y técnicas que aprendemos a lo largo de nuestra carrera, y es en esa parte de la curva cuando optamos por abandonar o seguir con el camino que hemos iniciado.
El problema con TDD es que para mentes como yo, ese proceso es duro y es muy fácil desistir y abandonar, el lado oscuro siempre nos tienta, es más fácil, más rápido y más seductor no seguir por el camino de TDD.
Continuamos con la pregunta de ¿hay que hacer TDD siempre? En el camino del aprendizaje, nos vamos dando cuenta de que es descabellado hacer TDD en todo. En ese camino se aprende a ser pragmático y a ajustarse a las necesidades del proyecto y del momento en el que estamos trabajando. Pero sobre todo, se aprende en ese camino a diseñar. TDD no es sólo una herramienta de testing, es mucho más, es una herramienta de diseño. En el camino de maestría de TDD se aprende sobre todo a diseñar, y con el tiempo se consigue empezar a acertar en esa primera “arquitectura” que pintamos en un papel. Normalmente los problemas que resolvemos suelen ser parecidos, y vamos mejorando esa arquitectura que dibujamos al principio.
Como última ventaja que le veo a TDD es que cuando no tenemos claro cómo solucionar un problema, TDD ayuda a encontrar una solución, empezando a escribir ese primer test de aquello que queremos programar pero no tenemos claro cómo hacerlo. Conseguimos tener un diseño desacoplado, abierto a la extensión y cerrado a la modificación, etc.… De esta forma cuando averiguamos qué es lo que hay que hacer nos es más sencillo modificar esa arquitectura.
Después de todas las experiencias que vimos, es curioso que siempre los que suelen ir a este tipo de eventos, y tu que estás leyendo esto, son siempre profesionales que buscan formas de hacer mejor su trabajo.
Quiero dejaros algunos nombres y libros que surgieron en la conversación, se que me falta alguno, así que si te acuerdas déjamelo en los comentarios:
Muchas gracias a Cartuja .NET por reunir a todos los que allí nos juntamos, ha sido una tarde muy agradable y tengo la sensación de que todos nos quedamos con ganas de más.
Estoy deseando ver la visión de cada uno que asistió, bien en los comentarios de este humilde blog o con referencias a los blogs de los que allí nos juntamos. No quiero señalar http://javiersuarezruiz.wordpress.com/, http://www.variablenotfound.com, http://cartujadotnet.es/
Se me olvidó comentar que mañana es el de Global CodeRetreat http://globalday.coderetreat.org/
En Madrid lo tienen preparado: http://madridcoderetreat.wordpress.com/
Si podéis verlo seguro que os gustará.
juanlao 