People have been verifying software since software was created.
Manual verification is indeed more complicated, slow and prone to failure but it's not worthless as the TDD people paint it, not TDD is the holy grail (it has a lot of deficiencies that seem to be ignored by the TDD people)
Also, UBob is lashing other testing DHH proposes in the text, but guess what, it's meant to test what TDD doesn't reach.
You can have 100% coverage of your tests with TDD and still have a bug.
"Manual verification is indeed more complicated, slow and prone to failure but it's not worthless"
Manual vs. automated is a whole other discussion, rather separate from TDD.
Manual test scripts are not worthless, but are certainly an indication your project is either (a) very small scale or simple or (b) going to take a very long time to complete and be prone to regressions.
TDD is about the benefits derived when you write your test case before your code, and also the design implications of doing so.
"You can have 100% coverage of your tests with TDD and still have a bug."
Obviously. But the probability of your codebase having defects goes down drastically with higher code coverage.
You could take the new radical approach of "don't test, just ship", but that requires a very specific organizational culture and risk profile.
Manual verification is indeed more complicated, slow and prone to failure but it's not worthless as the TDD people paint it, not TDD is the holy grail (it has a lot of deficiencies that seem to be ignored by the TDD people)
Also, UBob is lashing other testing DHH proposes in the text, but guess what, it's meant to test what TDD doesn't reach.
You can have 100% coverage of your tests with TDD and still have a bug.