I want to know how to prove TDD is best compared to code inspection in terms of time and cost.
closed as not a real question by gnat, Kilian Foth, Steven A. Lowe, dietbuddha, ChrisF♦ Feb 19 at 8:44
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, see the FAQ.
You won't be able to prove "TDD is best", because it isn't true.
It's not an either/or decision, they are orthogonal techniques and if you want your code to be any good, you probably should be thinking about doing both.
Just because you use TDD doesn't mean you code will pass a quick eyeball inspection.
TDD is a great methodology - it doesn't allow you to wander too far away from small, maintainable sections of code. However, it's no substitute for peer reviews or any other sort of review process. It also doesn't act as a saving grace from compliance tests (OWASP or anything to do with PID).
It's also the case that people can forget to "refactor" - which means they're not really doing TDD - but it happens. A code review/inspection will serve as a reminder or prodding to ensure that those refactorings get done - for any reason such as code style, unsafe checking, unsafe double-null checking, or auto-unboxing when not really desired.
Quality control is a well researched topic. Caper Jones has a paper that shows the effectiveness of the various Quality Control methods. There is a rough and ready rule, the longer a bug exists for, the more it will cost to fix (in terms of both time and final product quality). .... Quality control in order of value (ROI), most valuable first: Requirements inspection, design inspection, code inspection, TDD. (I have yet to see any science that disagrees with this order.)
The nice thing about TDD, is most programmers "get it", without having to do training. (Inspection tends to require a training course.)