TDD desde una perspectiva arquitectural

La semana pasada di una conferencia por teléfono para todos los arquitectos que trabajan para proyectos internos de IBM y que con planes de utilizar metodologías ágile y/o ya están utilizando. Fue una linda y desafiante experiencia debido a que había gente de muchas partes del mundo (USA, Francia, India, Sudamerica, etc), nunca había dado una charla técnica en inglés (sacando las presentaciones de arquitectura de la aplicación) y yo pongo un 4, creo que aprobé, pero tengo mucho que mejorar. Independientemente de esto, creo que lo más interesante que quiero comentar en el post es sobre las influencias que tiene TDD en lo arquitectural, esto es el resultado a una pequeña investigación que vengo haciendo para APIT sobre Arquitecturas y Metodologías Agiles. El contenido básicamente fue el siguiente.

Facts acerca de TDD

• TDD se compone de, Unit Test, Test Automation, Test First y Enfoque iterativo con refactoring
• TDD es una técnica de diseño y es utilizada por Desarrolladores (Código).
• TDD incrementa la calidad en el código facilitando el cambio en el software
• TDD reduce defectos y permite tener un testeo de regresion constante
• El manejo de dependencias es la parte más dificil de TDD

Requerimientos no funcionales impactados por TDD
Como siempre digo, las decisiones arquitecturales habilitan los atributos de calidad, pero obviamente no siempre los garantizan, hay otros aspectos y decisiones que entran en juego y el arquitecto no siempre puede manejar. Pero inevitablemente, la Arquitectura es la principal responsable de garantizarlos, y como arquitectos debemos buscar las formas, y TDD es una de ellas, con lo cual considero que TDD permite lograr los siguientes atributos de calidad:
Maintainability: Siguiendo las guías de Feathers, primero haciendo fallar el test case y luego corregirlo, la mantenibilidad se vuelve un detalle, lo mismo pasa con lo simple que queda el código y con la no necesidad de perder tiempo en un debugger. No nos olvidemos del regression test aca.
Extensibility / Modifiability: Esto es básico, como excelente técnica de diseño, al tiempo de aplicarla la productividad aumenta y el código queda mucho mas simple.
Reliability: Tiene que ver con la robustez en lo que respecta a las reestructuraciones o cambios en la arquitectura, un codigo que se construyo utilizando TDD, difícilmente sea complicado de modificar a cambios inesperados
Geographic (including Localization): TDD es una excelente técnica de comunicación, para equipos distribuidos es fundamental, tener bien claro y definido cual es el comportamiento esperado, no se paga con mastercard
Time: Ya hablé de la Productividad que trae aparejada el Test First, aca hay un paper que habla de los estudios que aumenta la productividad, hasta que lo leí fue solo un feeling mio y personal, ahora se ve que está probado.

Decisiones Arquitectónicas para Soportar TDD
Ahora, como (re) diseñamos nuestra arquitectura para soportar el uso de TDD, bueno, lo encaré desde el punto de vista de "Tácticas y Principios de Diseño" y "Estilos Arquitectónicos y Diseño Estratégico":
Tácticas y Principios de Diseño

• Separation of Concerns.
  Una correcta separación de módulos, permite un mejor manejo de la complejidad y también permite el reuso del lado de los Test Cases (que no es poco)
  
• Separación de la interface de la implementación.
  Hace falta explicar esto? Bueno, principalmente es para el manejo de dependencias y el trabajo en paralelo
  
• Design by Contract
  Dos técnicas complementarias en el bajo nivel, desde un punto de vista arquitectural, definir los pre/post conditions entre módulos es básico
  
• Informacion hiding
  Previene cambios no deseados
  
• Prevent Ripple Effects
  Con 8 tipos de dependencias entre módulos, nos ayuda a no tener dependencias ocultas entre módulos, esto es muy importante, muchas veces hay modulos que dependen en variables de contexto y está oculta, TDD ayuda a evitarlo.
  

Estilos Arquitectónicos y Diseño Estratégico
Mas allá de cosas específicas, hay estilos arquitectónicos que ayudan muchísimo al uso de TDD en aplicaciones empresariales, estos son algunos:

• Inversion of Control/Dependency Injection
  Aca no hay nada que discutir, por excelencia permite permite el uso de TDD, sumado a esto la separación de interface de la implementación.
• Hierarchical Layers
  Estilo super conocido, con un modelo sencillo de dependencias, permite el coverage de una layer solo mockeando una layer inferior. Obviamente este patrón tiene cosas malas aparejadas, como la dificultad por encontrar las abstracciones y la modificabilidad.
• Domain Driven Design
  Un estilo muy interesante para dominios complejos, se lleva muy bien con el Dependency Injections y la Iteratividad.
  
• Transaction Scripts
  Modelo sencillo, en donde se puede lograr una completa de cada servicios a testear.

Acá estuve hablando como 30 minutos, es un poco difícil plasmarlo en un post, pero obviamente es la parte más interesante de la charla (al menos para mi)

Quejas de otros profesionales para implementar TDD y como solucionarla
No siempre es fácil convencer el uso del TDD, hay muchas quejas que hay que afrontar, aca puse las que fui recolectando, en algún otro post voy a poner lo que dije verbalmente, así que por ahora se lo dejo a uds para que piensen :)
Project Managers

• Toma mucho tiempo para escribir test y termina impactando en la productividad.
• Me siento mal por dejar afuera del proyecto a Testers y gente de QA
  

Architects

• No me importa TDD, es una técnica de bajo nivel para programadores
  
• No es necesario to test drive el código, la arquitectura cubre todas las posibilidades

Application Developers

• Toma mucho tiempo en correr los test cases
  
• No es mi trabajo testear mi código
  
• Pero compila!
  
• A mi me pagan por escribir código, no para escribir tests
  
• Las dependencias son difíciles de manejar y toman mucho tiempo
  

Esto es todo, espero que les guste y espero feedback! realmente quiero escribir un paper con esto

Que cosas no ayudan al TDD

Hoy tuve un viaje bastante pesadito de MDQ a BA, 8 horitas, se rompió el auto, llegamos BA a las 19 (o sea todos volviendo del trabajo) y que se yo... en fin estuve pensando en que cosas molestan y mucho al la hora hacer TDD, obviamente tienen más que ver con el el buen diseño y la programación también, estas fueron mis ideas:
Métodos Estáticos
Esta es una de las cosas que más me molesta y sobre todo se vuelve un problema cuando los desarrolladores no utilizan los conceptos de OO y siguen trabajando o pensando en Estructurado. Los métodos estáticos son una mala práctica, realmente no justifico su utilización. Para los que no los notaron, los métodos estáticos son un problema a la hora de querer modificar su comportamiento para poder ejecutar cierto escenario del comportamiento unitesteado, existe varias técnicas para poder evitarlos.
Singletons.
Hay algo para decir aca? Realmente yo a los Singleton los veo como un Anti Pattern, raramente justifico el uso. No solo son dificiles de mokear sino que tambien son muy complicados para unitestear, siempre tenes que caer en agregar un método solo para la hora del testeo.
Service Locators
Piensen lo siguiente, como se implementa un Service Locator, Singleton + Métodos Estáticos, o sea que más puedo decir :) y si, algo más tengo para decir, si bien está claro que IoC es muy superior en terminos de manejo de dependencia y el 60% de los problemas del TDD tienen que ver con el manejo de dependencias, la implementación incorrecta de un Service Locator puede obligarte a no testear absolutamente nada de tu código. Está claro que si se implementa correctamente (no métodos estaticos y no singleton) puede no ser tan malo en terminos de TDD, igualmente dudo que decida utilizar TDD utilice un Service Locator en vez de IoC y DI.

Hasta aquí son las tres cosas que más podrían molestar o en algunos casos fracasar el uso de TDD, y ahora que estoy terminando el post veo que todos tienen que ver con el manejo de la dependencia de objetos... en conclusión, si queres usar TDD y tenes posibilidades de tomar decisiones sobre como se está construyendo un sistema, sinceramente te recomiendo que evites estas tres cosas y trates de focalizarte en como vas a hacer el manejo de dependencias, no estoy diciendo que tengas que usar si o si un IoC framework (cosa que tiene mucha onda en muchos casos) pero si que lo tengas muy en cuenta.

Está claro que lo que acabo de decir puedo asegurar que aplica principalmente con java, todavía quiero ver que pasa con lenguajes dinámicos como Ruby o Smalltalk, creo que no debería cambiar mucho, pero por algo DI no es algo que se usa en Smalltalk, quizá sea o por que son cerrados o realmente no lo necesitan por las características del lenguaje. Es una charla que me debo con Esteban Lorenzano, siempre que intenté tenerla nos fuimos por la tangente. En el caso de Ruby, lo poco que hice la injección de dependencia fue bastante sucia redefiniendo en runtime el comportamiento de las clases, cosa que no está del todo mal, pero prefiero el DI.