4 ms·

I need to clarify. I'm not talking about manufacturing I'm talking about protoyping and design. Software deevelopment is analogous to making the protoype, not t

by Aqueous 13y ago

I need to clarify. I'm not talking about manufacturing I'm talking about protoyping and design. Software deevelopment is analogous to making the protoype, not the copies. A replica of the prototype should be able to pass the same tests the prototype can - that's why manufacturers can get away with only testing a sample of them. You can be sure that the protoype has gone through rigorous specifications testing. I think that you can look at part specifications as writing a test. The component we're aiming for has to meet x, y, and z standards. Then you design the component, then you make sure it meets those standards. If not, iterate. Pretty analogous, I'd say.

jholman 13y ago
I agree with what you said in THIS comment, but it makes it even more obvious that your previous comment contains untrue statements. You think car manufacturers practice TDD with their prototypes? Ha! People who are building physical prototypes... 1) don't test first (they test AFTER building the prototype), and 2) don't use automated tests to avoid regressions, at least not typically Bottom line, there's nothing even approaching TDD in physical-goods manufacturing. Maybe you don't know what TDD is, and have assumed that "tdd" means "good testing"?
- Aqueous 13y ago
  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.

by Aqueous 13y ago

jholman 13y ago

I agree with what you said in THIS comment, but it makes it even more obvious that your previous comment contains untrue statements. You think car manufacturers practice TDD with their prototypes? Ha! People who are building physical prototypes... 1) don't test first (they test AFTER building the prototype), and 2) don't use automated tests to avoid regressions, at least not typically Bottom line, there's nothing even approaching TDD in physical-goods manufacturing. Maybe you don't know what TDD is, and have assumed that "tdd" means "good testing"?

Aqueous 13y ago
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.