> If you want your tests to catch exceptions you need to wrap them in
> exception handlers, which you could write a macro to do for you; as Eric
> noted though you need to be careful to preserve source locations.
>
This gave me an idea, so I've been reading *rackunit* docs finally. I'm
about halfway through and I don't exactly understand the machinery yet but
with your note above and what I've read so far the following code actually
does what I want:
(module+ test
> (require rackunit)
> (define-check (my-check pred thunk)
> (with-handlers ((;; exn predicate
> (λ (exn) (and (not (exn:test:check? exn))
> (exn:fail? exn)))
> ;; exn handler
> (λ (e) (with-check-info (('exn (make-check-info
> 'error e)))
> (fail-check)))))
> (check-pred pred (thunk))))
> ;; throws
> (my-check identity (thunk (f)))
> ;; fails
> (check eq? 2 3)
> ;; succeeds
> (check eq? 3 3))
Here's the output that preserves location of the check that failed:
--------------------
; FAILURE
; /Users/russki/Code/fcgi-rkt/play.rkt:24:2
name: my-check
location: play.rkt:24:2
params: '(#<procedure:identity> #<procedure:temp4>)
exn:
#(struct:check-info error #(struct:exn:fail "f-failed"
#<continuation-mark-set>))
--------------------
--------------------
; FAILURE
; /Users/russki/Code/fcgi-rkt/play.rkt:26:2
name: check
location: play.rkt:26:2
params: '(#<procedure:eq?> 2 3)
--------------------
This is a good start I think. To make it useful you'd want to capture the
errortrace somehow, unpack and report it in the check-info. That is you
report both the failed test location and the exception with its errortrace.
I'm sure I'll soon find out how to do all that so that a) rackunit API is
used and b) report follows Racket and rackunit style as much as possible.
If you can help of top of your head, that'd be great. Also note the
necessity of wrapping the test body in a thunk, which is annoying but
understandable and the docs make a note as to why that is. We could fix
that and other boilerplate with a macro. I'm just trying to think how I
could minimize the damage to *rackunit* proper. Speaking of ...
It is tempting to build my own thing for testing but I'll resist it as best
I can. I'd much rather just have a tiny macro that doesn't interfere with
rackunit and doesn't impose my oft ill-advised and rash preconceptions. The
more I read rackunit docs the more I'm convinced I wouldn't be able to
improve on it without making a big mess. It is possible that I'm going to
run into more annoying little gotchas that I'd want to fix, but I'm not
there, yet. Please, don't let my current attitude stop you.
--
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.
