Ruby people praising TDD is like hearing Java people blown away by Design Patterns or C people talk about techniques for avoiding buffer overflow errors: Sure, it's a good thing that they're trying to improve the quality of their software, but to some extent their methodologies are compensating for tradeoffs (and sometimes just flaws) in those languages. The trick is telling when they're genuinely useful techniques from when they're solving problems that could have been avoided entirely.

I don't think that all tools are bad, though; far from it. Just, sometimes it's better to address the root causes of problems, rather than symptoms. (Almost always better, in the long term, but deadlines happen.)

I'm working on a tool right now (not ready to share yet, it's a rare spare time project), working title "dehydrator" (like the DRY principle and hydras, dragons that keep growing more heads) which can scan code (or arbitrary sequences of tokens, really; it's an OCaml functor) and report on heavily duplicated patterns it finds. The motive is to help reintegrate code that has been copied-and-pasted to several places with only small changes. Obviously, the solution is Don't do that!, but the world is full of projects that already have years of cruft.