| Here is the infamous Nagappan TDD paper from Microsoft Research http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.... Also discussed in this infoq article http://www.infoq.com/news/2009/03/TDD-Improves-Quality Here's someone's thesis paper on it, with data: http://www.nomachetejuggling.com/files/tdd_thesis.pdf There's also interesting discussions like this http://programmers.stackexchange.com/questions/206355/the-re... "it is my experience that the value proposition for TDD grows exponentially as the time and resources involved in a project grows linearly." This has also been my own experience. This person's comment also is interesting and has data http://programmers.stackexchange.com/a/210756 Some of the above is empirical (read: scientific, no-bullshit) data. My opinion on it has grown to the point that I think TDD should literally be inseparable from programming, and the two together should simply be called, "programming." Lacking any unit tests whatsoever (TDD or otherwise) should be called, "taking stupid, extremely hazardous risks to save a little time, like reading your phone while driving" I've not found a programming task in at least 5 years that wasn't waaaay better-written when done via TDD. Some things, like IO, can be a challenge to unit-test, but that's why we have great ideas to solve that like Gary Bernhardt's awesome "Boundaries" talk https://www.youtube.com/watch?v=yTkzNHF6rMs |