Hi Daniel,
Yep that was my thinking. Something like:
: unit-test ( output input -- )
[ 2array ] 2keep [
{ } swap with-datastack { } rot with-datastack assert=
] 2curry (unit-test) ;
would do the trick and as far as I can see work with the existing unit
tests. (although I might be missing something)
Cheers,
Phi
Daniel Ehrenberg wrote:
> That's true, but it should be possible to do things like (as you kind of
> showed)
> [ 2 2 + ] [ 2 2 * ] unit-test
> and have useful output showing the differing results of each
> quotation. I think this would be a useful superset of current
> unit-test behavior, and not difficult to implement. (Right now, the
> first quotation is treated as a static stack and not executed. Maybe
> it should be changed to an array, to indicate that.)
>
> Daniel Ehrenberg
>
> On 11/6/07, Doug Coleman <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> If unit-test worked like you wanted, your first unit test wouldn't
>> test much besides "does the quotation I'm testing throw an
>> exception", because if [ 2 3 + ] somehow returned 7 it would still
>> pass. So a better unit test would involve checking a known answer,
>> like [ 5 ] [ 2 3 + ] unit-test.
>>
>> A way around computing the answer is to do it in the test quotation.
>>
>> [ t ] [ 2 2 * 2 2 + = ] unit-test
>>
>> [ t ] [ { 2 3 3 5 6 7 } >ulong-array dup natural-sort = ] unit-test
>>
>>
>> Doug
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
