2 ms·

Well, no, TDD doesn't necessarily change the output of a programmer. Even if you require 100% test coverage on every commit (which isn't the point of TDD anyway

Well, no, TDD doesn't necessarily change the output of a programmer. Even if you require 100% test coverage on every commit (which isn't the point of TDD anyway), there's no way to tell if the tests were written first. It is a "design standard", sure, but so is the nearly universally maligned waterfall process. Easily changed code that does what the programmer intended is better described as "good design". TDD is a useful design aid, but there's a lot more to good design than just TDD. If you are hitting that requirement, it is because you have good programmers, not because TDD is magic. Fancy type systems don't do much to ensure good design, either. Just like a really nice saw doesn't guarantee a beautiful cabinet.

unclebobmartin 14y ago
Interestingly enough, in 2009 Keith Braithwaite concocted a metric that can pretty reliably determine whether a system has been written with TDD or not. See: http://peripateticaxiom.blogspot.com/2006/05/complexity-and-test-first-0.html http://peripateticaxiom.blogspot.com/2006/05/complexity-and-...
- thomasmeeks 14y ago
  That's cool, and I'm sure the author's conclusions are correct for that code base. However, the skeptic in me can't help but point out that this is not nearly rigorous enough to say his method can pretty reliably determine TDD vs non TDD code in the general case.