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