The difficulty and pain of TDD adoption is a hot topic over the last couple days. I’m working on an article on testability and design this morning. In writing the summary I caught myself saying that there are some exceptional cases where I do unnatural things to promote testability, but that most of testability design is really a stronger focus on the classical OO design qualities of cohesion, coupling, and separation of concerns. Here’s the question of the day though, most of those “exceptional cases” and “unnatural things” are directly related to working around C#’s static type system (marking things as virtual, exposing members as public or doing the InternalsVisibleTo trick, etc.). Here’s the question of the day:
Will you adopt a dynamic language like IronRuby or try out “side effect free” programming with functional languages like F# just because of the lower friction in TDD from these languages? There’s an obvious cost and risk in switching over, not to mention less tooling, but at what point do we say that there’s more potential for higher productivity in these other languages for TDD practitioners and make the jump. My team considered Ruby on Rails early on, but chose to use C# 3.0 mostly out of familiarity and a feeling by Chad & I that it was a low risk choice.
How much of the TDD adoption obstacle is that our mainstream programming language isn’t entirely TDD-friendly?
Of course, everytime I curse Anders for making methods nonvirtual by default I remember that he saved us from checked exceptions and remembered to put first class delegate into the language from day one and all is forgiven.