Comment by bee_rider
If you were going to write the tests anyway, the additional boilerplate for splitting it up and doing a wrapper isn’t so bad (in C at least, maybe it is worse for some language).
If you were going to write the tests anyway, the additional boilerplate for splitting it up and doing a wrapper isn’t so bad (in C at least, maybe it is worse for some language).
Well, I was working on a sort of green-field project that did this, and I liked it. It neatly solved the problem of needing the tests, but only wanting to call them on user-provided inputs. However, some caveats:
* I wasn’t around long enough to see if there was a hidden maintenance cost
* It was a very thoughtfully designed library in an already-well-understood domain so it wasn’t like we were going to need to change the arguments a ton
* It was explicitly a library designed to be used as a library from the get-go, so there was a clear distinction of which functions should be user-visible.
I think I would find it annoying if I was doing exploratory programming and expected to change the arguments often. But, in that case, maybe it is too early to start checking user inputs anyway.
When you say "isn't so bad", is it just a manner of speech or is it actually a little bad (but it is a compromise?)?