Simulating I/O errors [was: assume, assert, enforce, @safe]

[Walter Bright via Digitalmars-d]

On 8/1/2014 1:02 PM, H. S. Teoh via Digitalmars-d wrote:
> Not to mention, it lets you *really* unittest your code thoroughly,
> because it isolates each separate stage of the processing into its own
> self-contained unit, with clearly-defined standard interconnects. Your
> unittest can therefore easily hook up with the unit's interfaces, and
> inject arbitrary inputs to the unit and run arbitrary tests on its
> output -- without needing such hackery as redirecting stdout just so you
> can confirm correct computation of a numerical result, for example.
>
> In the traditional imperative programming style, you often have code
> that has loops within loops within loops, with complex interactions
> between each loop body and its surrounding context. It's generally
> impossible (or very hard) to extricate the inner loop code from its
> tightly-coupled context, which means your unittest will have a hard time
> "reaching into" the innards of the nested loops to verify the
> correctness of each piece of code.  Often, the result is that rather
> than testing each *unit* of the code, you have to do a holistic test by
> running the entire machinery of nested loops inside a sandbox and
> capturing its output (via stdout redirection, or instrumenting dependent
> subsystems, etc.) -- hardly a *unit* test anymore! -- and still, you
> have the problem that there are too many possible code paths that these
> nested loops may run through, so it would be hard to have any confidence
> that you've covered sufficiently many paths in the test. You're almost
> certain to miss important boundary cases.

I agree and want to amplify this a bit. When a function accepts ranges as its 
input/output parameters, then the function tends to be a template function. This 
means that it becomes easy for the unittests to "mock up" ranges and feed them 
to the function to test it.

I've used this to great success with Warp.