Your caller should know what the impact of calling your function is. If it has side effects or dependencies (such as requiring sockets to be available, stomping on global variables, requiring filesystems to be writeable, or so forth), those restrictions should be published as as part of the function interface, so that they can be tested, by someone other than the author of the code.
If a tester can get an undocumented side effect from calling a given function, that's a bug in the code, or the code documentation. Either is bad.
How much this matters depends on what you're dealing with, and what failure modes you can handle. If, for example, you're sure your production server can't possibly run out of filehandles, because it will crash due to other limitations long before that becomes an issue, perhaps there's no real viable way to test, let alone recover from the "out of filehandles" condition. If you document your position, it's at least a calculated risk, not just an accidental assumption, and if it proves to be false, you at least have a explanation for why the choice to ignore it was made. And if/when you upgrade your server, you'll catch the limitation of the software when you read through the limitations list for all your server code prior to the upgrade.
--
AC
In reply to Re^7: Neither system testing nor user acceptance testing is the repeat of unit testing (OT)
by Anonymous Monk
in thread Neither system testing nor user acceptance testing is the repeat of unit testing (OT)
by pg
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |