On Sun, Aug 28, 2011 at 6:02 AM, Eli Barzilay <e...@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.
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/users
