3 ms·

You can also replace it with vaccines, evolution and climate change. I have the feeling that, while TDD is not an absolute, this article doesn't put forward go

by pyrale 10y ago

You can also replace it with vaccines, evolution and climate change. I have the feeling that, while TDD is not an absolute, this article doesn't put forward good case examples for skipping it, or at least doesn't try to discuss these examples and find out why they aren't fit. Instead; it takes a shot at stereotypes and builds a strawman on it.

Jtsummers 10y ago
The article is calling for moderation, not saying you should skip TDD but that you should understand what the exceptions are in TDD for when to write and when not to write tests. The author is asking the experts in TDD (and, implicitly, other methods that become dogma) to qualify their statements rather than issue commandments to "always write tests first" (a statement you see in material instructing on TDD, but then later gets qualified to show where and when to actually write those tests first and where and when not). But since many people probably don't read past the first few chapters, they miss the nuance.
- 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

The article is calling for moderation, not saying you should skip TDD but that you should understand what the exceptions are in TDD for when to write and when not to write tests. The author is asking the experts in TDD (and, implicitly, other methods that become dogma) to qualify their statements rather than issue commandments to "always write tests first" (a statement you see in material instructing on TDD, but then later gets qualified to show where and when to actually write those tests first and where and when not). But since many people probably don't read past the first few chapters, they miss the nuance.

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).