[racket] tests/eli-tester feedback

On Mon, Feb 14, 2011 at 4:53 PM, Eli Barzilay <eli at barzilay.org> wrote:
> Two minutes ago, Robby Findler wrote:
>> I guess I'm asking if true is bound somewhere or not.
>
> Ah -- I should have remembered that point.  Yes, I meant that it is
> bound.  I should have also said that `true' is a bad name for this
> reason, in the same way that `->' is (I'd prefer it over `=>').

FWIW, existing convention in Scheme literature for "evaluates to" is
already "=>" so, in my mind, we lucked on out on this one. :)

> BTW,
> this leads to another requirement -- the "namespace pollution" should
> be minimal since you don't want code to change (as in `true' getting
> some strange value for tests) because you use tests.

Yes!

> In any case, if this is a sane approach, then maybe it can be used for
> the multiple values and the exceptions case too.  Something like this:
>
>  (test E1 => true-result
>        E2 => (values-result 1 2)
>        E3 => (raised-result 666))

I prefer to not have true-result and just deal with the (and E1 #t) =>
#t or add an =/=> arrow.

As for multiple values, I think that => should deal with that already.
Ie these should all be passing tests:

  (test 1 => 1)
  (test (values 1 2 3) => (values 1 2 3))

and this should be a failing test (not a runtime error (necc)):

  (test (values 1 2) => (values 1 2 3))

For raised-result, I think that's uncommon enough that writing

  (test (with-handlers ((values values)) E3) => 666)

is just fine.

I take my cue here from what I see as the essence of the design of
your test library, namely its minimality (I also really like this
idea).

I think adding extra arrows (or having support for defining them) to
capture things like state initialization (aka "setup" and "teardown")
and catching IO is the right way to go. And if these arrows always
have the form "=something=>" (replacing something), then they will be
iconic and easy to look up if the name is not enough to be able to
guess.

My $0.02,
Robby