> 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.