3 ms·

The whole point of TDD is to submit one's code to experimental validation. It seems wrong that, in order to better grasp it, one should be taught all the counte

by pyrale 10y ago

The whole point of TDD is to submit one's code to experimental validation. It seems wrong that, in order to better grasp it, one should be taught all the counter-examples. Moderation comes from practice, in fact. It comes from trying and failing, not from extra-prodding the experts, or from studying the matter. And should one be confronted with a zealot, their experimental rebuttal should be convincing enough that zealotry isn't a problem. On the other hand, OP's assertion that, e.g. a pseudo random generator shouldn't be tested comes without explanations, and frankly is unconvincing : there are acceptance tests (they may not be enough, but passing them is the least you can do) https://en.wikipedia.org/wiki/Randomness_tests https://en.wikipedia.org/wiki/Randomness_tests, and you can also split the seed and the function you implement, and test thoroughly that the function performs what the algorithm describes.

Jtsummers 10y ago
That's not the whole point, that's a point. It's also got a large emphasis on testing frequently, writing tests frequently, and writing them in close temporal proximity to the code (dogmatic preference is before, but practically the order is less relevant), and writing or executing tests after relatively small code changes (additions, deletions, modifications).
- pyrale 10y ago
  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 someone that writes zero tests but has an inexpensive and permanently available source of validation (e.g. from prod) practices TDD.
  - 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).

by pyrale 10y ago

Jtsummers 10y ago

That's not the whole point, that's a point. It's also got a large emphasis on testing frequently, writing tests frequently, and writing them in close temporal proximity to the code (dogmatic preference is before, but practically the order is less relevant), and writing or executing tests after relatively small code changes (additions, deletions, modifications).

pyrale 10y ago
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 someone that writes zero tests but has an inexpensive and permanently available source of validation (e.g. from prod) practices TDD.
- 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).