Hace un tiempo escribí sobre los estilos de TDD e intenté hacerlo de forma objetiva. Ahora pretendo continuar con la cuestión pero dando mi opinión.

No creo que haya un estilo que sea universalmente mejor que otro (no silver bullet). Creo que un determinado contexto puede resultar más conveniente utilizar uno u otro estilo. Personalmente me ocurre que en los contextos en los que suelo trabajar encuentro más conveniente una utilizar una estrategia del estilo London, o para ser más preciso: la propuesta de Freeman & Pryce. Para que se entienda mi posición explico un poco las generalidades de los contextos en los que suelo trabajar.

En primer lugar suelo trabajar muy cerca del usuario y con una estrategia de entrega continua. Al mismo tiempo, en los equipos en los que trabajo suelo ocupar un rol tipo «XP Coach» con el foco en lograr que el equipo pueda entregar software de valor, de calidad, de manera sostenible y predecible. Generalmente los equipos con los que trabajo no tienen experiencia en TDD. Típicamente trabajo en aplicaciones comúnmente denominadas como de «tipo enterprise / sistemas de información» . Generalmente me ocurre que los principales desafíos que el equipo enfrenta no vienen dados por la lógica de negocio ni el modelado del dominio sino por cuestiones «accidentales» como procesos manuales, desconocimiento/(des)control de la infraestructura, trabajo desordenado, burocracia, falta de comunicación, etc.

Es en estos contextos donde encuentro especialmente útil la propuesta de Freeman & Pryce, concretamente cuando proponen:

• Comenzar con un walking skeleton que nos permita establecer las bases de la arquitectura de la aplicación de punta a punta.
• Que ese walking skeleton este cubierto por una prueba de aceptación end-to-end
• Incluir como parte de ese walking skeleton el proceso de versionado, build, test y deploy a un ambiente simil producción en un esquema de integración continua

Esto en un punto excede el estilo de TDD y por ello es me parece más preciso hablar de la propuesta de Freeman & Pryce que del estilo London cuando me refiero a estas cuestiones.

Ahora bien, una vez completo el walking skeleton entonces sí podemos hablar del estilo de TDD. Ahí la propuesta de Freeman & Pryce es comenzar «desde afuera» trabajando en el doble ciclo TDD (estilo London). Esto requiere del uso de test-doubles, posiblemente el punto más cuestionado de este enfoque. Las críticas a esta cuestión se deben principalmente al hecho de que puede resultar costoso el mantenimiento de los test-doubles a medida que la aplicación (y el diseño) van evolucionando. Coincido en que esta cuestión es un riesgo, pero en mi caso lo suelo mitigar tratando al código de tests con el mismo cuidado con el que trato al código de la aplicación y utilizando todo un conjunto de técnicas para asegurar su mantenibilidad. Muchas de estas técnicas están descriptas en el mismo libro de Freeman y Pryce, pero también hay algunas otras que he encontrando muy útiles en los libros de Gojko Adzic (Fifty Quick Ideas To Improve Your Tests, Specificacion by Example) y Gerard Meszaros (xUnit Test Patterns: Refactoring Test Code).

Una cuestión que quiero destacar de este enfoque es que me resulta muy conveniente la idea de ir diseñando/desarrollando la aplicación desde afuera porque eso nos pone en una posición de «cliente/usuario» de nuestro propio código, evitando en cierto modo la creación de métodos/comportamientos/atributos/artefactos que «el cliente» no requiera, entiendo aquí como cliente a «la capa/el objeto» que consume nuestro código y que indirectamente termina expresando la necesidad del cliente/usuario persona.