20 minutes ago, Noel Welsh wrote:
> 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?
Yes, of course.
> IIUC test arrows conflate getting output to test, and performing a
> check on the output. [...]
>
> (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.
And therefore I'd consider that a non-solution. IIRC, the main tricky
bit in the definition of `=output>' was making it so that both
(test foo => bar =output> blah)
(test foo =output> blah => bar)
work.
> 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.
Yeah, that's a valid point. If it's the *only* one for adding a
before/after to a testing facility, then the only problem I have with
it is in making it easier for the core developers to not face the
problem.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/users
