The similarities between building a physical thing and writing software are pretty minimal.
That said, there's one massive distinction worth pointing out:
There's a difference between "authoring a test" and "executing a test."
In the example of building a house, the requirements and tests do precede the physical buildout. And portions of the test suite are run continuously -- by multiple agents even! When the builder picks up a 2x4, he immediately and automatically "tests" the unit against his notion of "what a sound 2x4 looks like." He doesn't author requirements after he picks it up; he runs pre-existent checks on it.
Likewise for an assembled wall, an electrical box, the plumbing, etc -- the tests/requirements already exist; they get run implicitly and automatically by the trained eyes of everyone on the job continuously. Another suite of pre-existent tests are executed when the inspector visits. If the units were not built to pass those pre-existent test, they fail.
And likewise for the structure as a whole. The plans pre-exist the buildout. At every step of the way, the engineers are working towards a pre-existent set of conditions that the structure will ultimately be tested against when the buildout is complete.
That said, not every physical project needs to be preceded by a huge suite of tests. If you go to your workshop and start putting wood together for a toybox or something, letting your intuition and creativity guide you, that's not rigorous TDD woodworking. In that case, you're basically relying on the physical laws of the medium and your rough expectations to validate the work (i.e., "if it compiles and it works, it's good!").
And that's OK. Not everything needs to be preceded by rigorous tests.
tl;dr
Even though construction != writing software: Construction does operate in a test-driven fashion. The "passing" conditions for every unit do precede their buildout.
Don't conflate "executing tests" with "writing tests."
Not everything needs to be TDD.