3 ms·

Imho, that's the whole point. Testing frequently and using small steps is merely a question of how TDD is best used. Likewise, I would totally accept that some

• Jtsummers 10y ago
  > Likewise, I would totally accept that someone that writes zero tests but has an inexpensive and permanently available source of validation (e.g. from prod) practices TDD. I'm not sure how you can do validation without writing tests, but let's clarify our terms. I work in the embedded field. We rarely, if ever, write unit tests in the typical sense. Most tests are based on black box testing of the system (related to integration tests) sometimes of a system component if we can plugin a simulator of other components (closest we get to unit tests). Most often, these tests are not written in the same language as the system or even running on the same platform. They talk over serial or something to the device and record the responses back. These tests still have to be written, even if it's just: Send messages X, Y, Z Receive messages A, B, C as responses A, B, C should match *data* modulo time tag A test has been written. And if this testing is run frequently against the code changes, and failures treated typically as blockers on working on other features or issues, then this is definitely TDD. Often, however, these tests are run infrequently, ergo not TDD, despite the comprehensiveness of the test suite. The tests do not drive the development (though perhaps they should more often than not).