Uhm, yes. TDD, as you've already said, means write tests first, and then the function they test. The point of the test-first is to declare and define explicitly

Uhm, yes. TDD, as you've already said, means write tests first, and then the function they test. The point of the test-first is to declare and define explicitly what the specifications for the function are. So writing your tests first is pretty analogous to specifying exactly what you want your function to output given a specific input. I'm not sure what automated testing would like like in automotive part testing. This might be a situation where just because the technology doesn't yet exist for completely automated testing doesn't mean it's not the right thing to do, and therefore software can lead in this regard. I don't think the automation part of TDD is essential or definitive, just very nice to have, but the test-first philosophy is essential. I think you can look at the specifications process as writing a test that you assume will fail, insomuch as you are defining the exact conditions of success and don't yet have a component to meet those conditions. Then you are creating the prototype, then running the test, and iterating the prototype until it passes.