4 ms·

It still treats the whole stack as a blackbox. Necessarily the effort to cover important boundary cases throughout the TCP stack can get overwhelming.

• ori_b 11y ago
  Honestly, I've found black box testing at public boundaries of a system gives the best payoff vs development time, especially if you can make them run quickly. Most issues seem to be catchable with this, and way too many unit tests end up becoming 'change detector' tests, where you test tautologies about implementation details.
  • gsnedders 11y ago
    Black-box testing as a first move is often a good move, IMO — but it's important to accept that at some point you're going to stop hitting so many edge-cases in the implementation that ought be tested. Some of those edge-cases should probably be tested with black-box tests, and some should probably be tested with unit tests. One has to consider the performance cost of black-box tests, though. It will almost always be higher than that of unit tests, simply because more code will get run per test (this is especially true of network stuff, as even going through the loopback device is comparatively insanely expensive). That said, in some cases, it may well still be the right choice.
  • golergka 11y ago
    > black box testing at public boundaries of a system But that sounds more like integration testing, not unit testing, doesn't it?