On Oct 28, 10:46 pm, Abdulaziz Ghuloum <[EMAIL PROTECTED]> wrote:
> On Oct 28, 2008, at 5:42 PM, Abdulaziz Ghuloum wrote:
>
> >> To test execution paths that react to error exit codes and
> >> signals, which are not always easy to simulate by controlling
> >> the child process behaviour.
>
> > You can always make a wrapper around these procedures that
> > returns a record with the interface that you like.
>
> These are also known as "mock objects":
>
> http://en.wikipedia.org/wiki/Mock_Object
Which means more boilerplate work to test code like this
(which I can encapsulate in a small adapter library):
(define (decide-what-to-do wstatus)
...)
(define (run-process ...)
(...
(decide-what-to-do (waitpid ...))
...))
because I have to do:
(define (decide-what-to-do my-wstatus)
...)
(define (run-process ...)
(...
(decide-what-to-do (wstatus->my-wstatus (waitpid ...)))
...))
and design a 'my-wstatus' object, which itself needs to be
unit-tested like everything else. And of course the first
version of 'my-wstatus' will be a record with the same fields
of 'wstatus', a clone of it (why should I change it now that
it has to adapt a single record type?).
Is it not the library the main tool for encapsulation for
R6RS Scheme?
