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.