What I never understood about TDD is: why would one have to write the test first?<p>Now, I get that maybe the reason is human psyche and that one may not have the same discipline to write the test after the code. But, stripping that away, more logically asking, why does the test need to exist first?<p>I get that if you have a test, you have an exact "plan" of what your code needs to do/return and you then work on it until the test passes.. But isn't that the case already in any strongly typed language? You constrain the set of values your function can return to only the set of all valid values by defining a type (which is that set). (Okay I may have answered my own question, as we do define the expected type first).<p>I think that at the end of the day it comes down to finding a balance between complete formal validation of correctness and productivity/usability i.e. actually getting something done. TDD strikes me as a practice that slows you down a fair amount yet still doesn't offer anything close to complete formal validation, so it doesn't seem that attractive to me. But I still also wonder what alternatives are out there.