One reason to want that kind of functionality is to maintain good source
location information on test failures (which helper functions don't).

Robby

On Tuesday, March 8, 2016, Brian Adkins <lojicdot...@gmail.com> wrote:

> Jay:
>
> Here's a gist: https://gist.github.com/lojic/db7016fb95b1c05e4ade
>
> without.rkt is how I coded it up and with.rkt is how I'd like to be able
> to code it.
>
> I agree that it's trivial to add, but for something as common as "setup"
> and "teardown" for unit testing, there may be an advantage to having it in
> RackUnit. When it comes down to it, test-case, check-equal, etc. aren't
> hard to add either, but why should we all implement those.
>
> Brian
>
> On Tuesday, March 8, 2016 at 12:49:21 PM UTC-5, Jay McCarthy wrote:
> > Hi Brian,
> >
> >
> > Can you explain what you want to write? Just imagine that the feature
> was already there... what do you want?
> >
> >
> > I think of Rackunit as a way of writing checks, so if I wanted to do
> what you're talking about, then I'd define the macro/function that you
> don't want to. In other words, with Rackunit, you are just writing a
> program and it provides a way to keep track of and print out individual
> tests, so all the features of Racket are there for writing that program.
> There's no reason to add functions, dynamic-wind, and begin blocks to
> Rackunit, because they're already in Racket. For instance, my tests look
> like
> >
> >
> > (define f ....)
> > (module+ test
> >  (check-equal? (f ....) ....)
> >  (check-equal? (f ....) ....)
> >  (check-equal? (f ....) ....))
> >
> >
> >
> > and sometimes
> >
> >
> > (define (f ....)
> > (module+ test
> >  (define (test-f-like-woah ....)
> >    .... (check-equal? (f ....) ....) ....)
> >  (test-f-like-woah ....)
> >  (test-f-like-woah ....))
> >
> >
> >
> > If I had already done the second kind, then I'd put setup in there.
> >
> >
> > Given that Rackunit doesn't already have an "outer" paren, each check
> really is atomic, so any setup would be environmental, like wrapping in a
> dynamic-wind/parameterize or just another function call before the
> check-equal?.
> >
> >
> > Now, if you REALLY want this, and I don't feel that you should, you
> could look at current-check-around and do something like:
> >
> >
> > (let ([old (current-check-around)])
> >  (parameterize ([current-check-around (lambda (c) (before!) (old c)
> (after!))])
> >   (check-equal? ....)
> >   (check-equal? ....)
> >
> >   (check-equal? ....)))
> >
> >
> >
> > This would run (before!) 3 times and (after!) 3 times.
> >
> >
> > Jay
> >
> >
> >
> >
> > On Tue, Mar 8, 2016 at 12:23 PM, Brian Adkins <lojic...@gmail.com
> <javascript:;>> wrote:
> > Does RackUnit provide a facility similar to the setup & teardown
> functions of other unit testing frameworks? In other words, I'd like to
> execute some code before each test w/o coding each test to call a setup
> function or having to create my own macro given how common this is.
> >
> >
> >
> > As far as I can tell, neither the #:before of test-suite nor the before
> macro accomplish this. In fact, I haven't been able to discern the purpose
> of the before macro because the following seem equivalent to me:
> >
> >
> >
> > (before
> >
> >   before-expr
> >
> >   expr1
> >
> >   expr2)
> >
> >
> >
> > before-expr
> >
> > expr1
> >
> > expr2
> >
> >
> >
> > At least with the after macro, there is a guarantee that the after-expr
> will be evaluated in the face of exceptions.
> >
> >
> >
> > Also, as I mentioned in IRC, I just discovered that the setup function
> in Elixir (the love child of Erlang and Ruby :) returns an expression that
> each test accepts as input. This is more functional than the traditional
> approach of the setup function mutating a variable that the test cases
> access and allows the tests to run concurrently in the same file. Might be
> worth adding to a wishlist for future versions of RackUnit.
> >
> >
> >
> > Thanks,
> >
> > Brian
> >
> >
> >
> > --
> >
> > You received this message because you are subscribed to the Google
> Groups "Racket Users" group.
> >
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to racket-users...@googlegroups.com <javascript:;>.
> >
> > For more options, visit https://groups.google.com/d/optout.
> >
> >
> >
> >
> >
> > --
> >
> > Jay McCarthy
> > Associate Professor
> > PLT @ CS @ UMass Lowell
> > http://jeapostrophe.github.io
> >
> >            "Wherefore, be not weary in well-doing,
> >       for ye are laying the foundation of a great work.
> > And out of small things proceedeth that which is great."
> >                           - D&C 64:33
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com <javascript:;>.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to