So I am new to agile, but not test-driven development. My professors in college were all about the idea of tests then code then tests. I am not sure I understand why. From my perspective it is a lot of upfront cost that will most likely be changed as your code evolves.
This is how I imagine TDD and why it confuses me. If I were to build a house as a TDD contractor.
Give me all of your specs (stories).
Get approval on the specs.
Break down all the specs into inspection I think I will need (see into the future).
Call an inspector to look at those points and tell me right now I am failing the inspection (gee thanks).
Start building the house.
Call the inspector back out daily (passing 2/100).
Oh shoot, there was an issue with my understanding and now I need to add 9 more inspection and change 27 of them.
Call inspector passing 1/109.
Damn it. Why doesn't the inspector like this one... oh I updated that method name...
Build some more.
UGGGGHHHH MORE CHANGES let me update the damn inspector. Oh I am failing no s**t.
Am I done yet?
Okay, that may be outlandish, but I just do not see how I should know all my methods and how things will work until my code is there. 99% of the time I have to go back and update a unit test any ways and add more as I go. It just seems backwards.
What seems more appropriate is DDT or development-driven testing which is a thing the community has all but forgotten about it seems.
From my understanding DDT for a house would look like:
Give me all of your specs (stories).
Get approval on the specs and break them out.
Start a unit (the foundation).
Take notes (comments) of some tricky logic.
At the end before beginning the next unit have the inspection (create a test).
Fix any issue found and inspect again.
Approved this unit move onto the next.
If we are all being honest doesn't that sound more human and centered on the developer and business? It seems like changes can be made faster and without the overhead TDD seems to create.