[racket] Thoughts on Overeasy

From: Noel Welsh (noelwelsh at gmail.com)
Date: Mon Aug 29 05:39:57 EDT 2011

On Sun, Aug 28, 2011 at 6:02 AM, Eli Barzilay <eli at barzilay.org> wrote:
> This is exactly what I have in the future of my tester ("have" not in
> a complete vaporware sense, but as stuff that's already working and
> committed in my repo).  You basically get a macro that defines new
> arrow types
>
>  (define-test-arrow-rule (X =output> Y)
>    ...)
>
> and this macro set up the output redirection before the test, and
> checking the collected output after it.

Do (these) arrows compose? IIUC test arrows conflate getting output to
test, and performing a check on the output. Say I was writing a logger
and wanted to test the output to current-output-port and the returned
value. I'd rather write:

(test
  ;; Evaluates to a list containing the value of log-message and
current-output-port
 (with-output output (list (log-message "a string") output))
 ;; Compare to the value below using the default comparison (presumably equals?)
 (list (void) "a string"))

than something like

(test
  (log-message "a string")
  =output+value=>
  (list (void) "a string"))

The later is shorter but more opaque, and the number of arrows you
need grow exponentially.

> It has a huge advantage of already being there, separate from the the
> testing facility, and I didn't see any use that needs something
> special.  I think that it's even less likely that there's something
> special that is needed that is *not* also needed outside of a testing
> framework -- for example, some unroll-on-abort thing is obviously
> useful outside of testing.  Keeping things separate is always a good
> idea IMO.

I'm certainly happy to have Racket extended with before/after/around
forms that are conveniences for dynamic-wind. Us humble test package
authors aren't really in a position to do this, however.

N.



Posted on the users mailing list.