[racket] tests/eli-tester feedback (Was: Racket unit testing)

Yesterday, Stefan Schmiedl wrote:
> On Sun, 13 Feb 2011 12:16:59 -0500
> Eli Barzilay <eli at barzilay.org> wrote:
> 
> > Not documented, and not distributed by default (since it still
> > lives as just a file in the `tests' collection).
> 
> Hidden like an easter egg :-)

Not really.  Started as a private hack, grew to be a little more
useful, but still not enough to be a proper library.  (And this thread
is good evidence for that...)


> Naively speaking (and without reading any docs ;-), I'd expect => to
> handle "normal" operations. Using error-arrows is a good idea, as it
> makes it clearly visible that there's something going on here
> without clobbering the test descriptions.

Yes, that was Robby's point.  But there's another reason for this that
I forgot to mention earlier -- how would you test non-error exceptions
and multiple values.  The way it currently does things makes it very
easy to do that without "reifying" those as plain values -- you just
write the expected result expression on the right:

  (test (quotient/remainder 13 10) => (values 1 3))
  (test (foo) => (raise 1))

In this case there could also be more arrows to do these things, but
this goes back to a system that you'd have to open the manual to use,
and the other alternative that Neil raised is the idiomatic racket
code, which makes things inconvenient (you'd have to do that
reification using `call-with-values' and `with-handlers').


> I'm not convinced that you'd need more than one type of error arrow,
> though.

The line was that if catching errors can be surprising in a bad way,
then catching syntax errors is even more surprising.  (And that
correspond with tricks that the code does to catch them.)


> > b. Add some way to wrap all evaluations, so, for example, you can
> >    create a sandbox and have all evaluations happen inside it, so
> >    you can do things like:
> >      (test (some-loop) =error> "out of memory")
> >    which are only possible if the expressions are running inside a
> >    sandbox.
> 
> hm. Personally, I'm looking for a "small and easy" tester that I can
> use while teaching my son some basic programming skills. Between
> (check-expect whatever) and (assert-what's-it-called-again something
> or-other) your (test expr => result) is a very good fit for this
> task. I can live without that wrapper very comfortably :-)

Just to clarify -- the goal of that is really unrelated to any kind of
teaching.  That's the reason for the tests that the `test-engine'
colelction implements.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!