On Saturday, May 23, 2020 at 10:25:07 PM UTC+8, sk wrote:
> Thank you, Alex, this seems to have just the right set of information. I'm 
> curious why you use `foldts-test-suite` instead of  `fold-test-results`, 
> whose documentation says "Hence it should be used in preference to 
> foldts-test-suite 
> <https://docs.racket-lang.org/rackunit/internals.html?q=foldts-test-suite#%28def._%28%28lib._rackunit%2Fmain..rkt%29._foldts-test-suite%29%29>."

I no longer remember why I choose `foldts-test-suite`, I remember 
experimenting with a few approaches before settling on the current one, but 
looking at the code now, I think `fold-test-results` would have worked 
equally well in my case.

> (And while David's points about the verbosity are well taken, my TAs are 
> likely to be used to the rackunit primitives, though I think I'll consider 
> borrowing some of his aliases for shorter testing primitive names.)
> In the success case, the result seems to be `void` (rather than, say, a 
> value corresponding to the type of test). Are there cases where it's not 
> void?

I am not sure I understand this question: whose result is "void" and what 
would "A value corresponding to the type of the test" be?

> In the failure case, is there a procedure to convert the `exn:test:check` 
> value into a human-readable string? I'm guessing you have some 
> serialization process for the XML test report.

Unfortunately, I had to import some functions from the "private" section of 
rackunit. in particular, the display-test-failure/error function.

> Sadly, errors during test execution aren't sandboxed, so if there's an 
> error in a test, the whole suite breaks down. I think this means I'm going 
> to have to write custom testing procedures anyway.

I am not sure what "errors during test execution" means for you, but a 
check failure in a test case will not prevent other test cases from 
running, and neither will any other failure that raises an exception.  I'm 
sure a creative programmer can write a test case which will prevent other 
test cases from running, but the issue does not seem important enough to 
prevent them.

The "unit" is however the test case, not the individual check, so if a 
check fails inside a test case, other checks in the same test case will not 


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.
To view this discussion on the web visit 

Reply via email to