News for hackers. Stuff that matters.

A comment on The Pragmatics of TDD. Parent comment

Re:The Pragmatics of TDD by thomasmeeks on Wednesday March 06, 2013 @07:25PM (#5335059)
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.

[ Parent | on HN ]
Re:The Pragmatics of TDD by unclebobmartin on Wednesday March 06, 2013 @09:16PM (#5335553)
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-...

[ Parent | on HN ]
Re:The Pragmatics of TDD by thomasmeeks on Thursday March 07, 2013 @12:05AM (#5336208)
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.

[ Parent | on HN ]