[metaphor]

"usually"..."basically"..."probably"...that's a lot of handwaving. Your usecase is both your prerogative and your folly to embrace; that's not the point.

I poke fun at the OP because his qualifier for "works fine" is an indeterminate definition of eventually establishing some semblance of compliant 1-wire communication with a counterfeit component without even so much as batting an eye to question the accuracy of the sensor measurement being read in, let alone:

  a) environmental constraints
  b) electrical constraints
  c) timing constraints
  d) system integration considerations
  e) counterfeit variance/unpredicability

No, this is not even remotely asymptotic to the implications of software unit testing. This is physical hardware which manifests real variance "vetted" by some half-baked functional "test" that completely ignores every parametric spec without discrimination. Without questioning implementation merits, your software unit tests operate on hash-replicable code...at the silicon level, such a luxury doesn't exist.

[yjftsjthsd-h]

I think the difference here is that you're taking this from the perspective of an actual engineer, and I'm a hobbyist (and I assumed the same of OP; I hope Real Engineers aren't getting parts off eBay). Which means that, yeah, I'm happy to handwave a lot. By software analogy, I write a lot of shell scripts and python, which is passable but hardly rigorous; if I wanted it to be Correct, I'd break out coq or write in Ada or something, but I just want something that usually works because the stakes are so low. Of course counterfeit parts aren't reliable, but if failure is an option then they're good enough.