6 ms·
My experience with production/enterprise/whatever code has been that bugs at interface boundaries exceed bugs interior to an interface, so I like to check that
by jjoonathan 11y ago
My experience with production/enterprise/whatever code has been that bugs at interface boundaries exceed bugs interior to an interface, so I like to check that A plays nice with B plays nice with C rather than ensure that A, B, and C will be individually robust players in the game of blame volleyball. That won't save them from inter-component misunderstandings.
As always, exceptions: algorithms, logic hairballs, parsers, anything with a sufficiently low surface-area:volume is likely to generate significant bugs in the interior, so it can likely benefit from a unit test.
- lfowles 11y agoI'm writing a translation wrapper (very high surface area:volume), but I might have the advantage that A and B are in my project, so I can have a good idea of how they behave. C isn't, but I have an additional test suite for the small bit I use, just to make sure it behaves reasonably well, and that if it doesn't, that I recognize something is wrong.
- jjoonathan 11y agoYeah, that's reasonable -- haven't had to do that yet in production but I'd probably do the same.