3 ms·
As HW guy you are making the hardware so you can make a mock of it relatively easily, that is not the case if driver is essentially reverse-engineered out of ho
by ilyt 4y ago
As HW guy you are making the hardware so you can make a mock of it relatively easily, that is not the case if driver is essentially reverse-engineered out of how windows driver worked.
And many other drivers are "some vendor made it, and they won't tell us how the chip actually work, just give us driver code".
Then as other people mentioned hardware isn't exactly 100% predictable, HW bugs happen, firmware upgrades change how stuff works etc. so your test suite might be entirely unable to catch that.
- tails4e 4y agoI know hardware isn't 100% precitable, which is why we expliclty try to test that behaviour through randomized testing, formal proofs, etc. I'm not mocking anything, I'm just saying it's possible to attempt to cover difficult to create scenarios.
- asalahli 4y agoI believe the parent was referring to Test mocks[0], not implying you mocking anything. 0. https://en.wikipedia.org/wiki/Mock_object#Use_in_test-driven_development https://en.wikipedia.org/wiki/Mock_object#Use_in_test-driven...
- tails4e 4y agoI see, thanks. Well we do have events in HW that are non determistic, i.e. metastability due to async signal synchrinzation, but that is something we can and do model as best we can