As Leif mentions, RackUnit require/expose will allow the use of invalid identifiers in other modules, but its own documentation does not promise a very strong guarantee:
Note that require/expose can be a little fragile, especially if it is mixed with compiled code. Use at your own risk!
Another approach would be to use submodules , which can effectively provide an authorized way to export a private API for use in tests or other means.
For example, consider a module that implements a function to check if a string contains one word:
#lang racket (provide word?) (define (word? str) (not (ormap space? (string->list str)))) (define (space? c) (eq? c #\space))
(This is perhaps not the most realistic example, but carry me.)
Perhaps it would be useful to test the space? function space? to make sure it works, but it probably shouldn't be part of the public API. To create an escape-hatch, you can define a submodule that exports this binding:
(module+ for-testing (provide space?))
The name for-testing arbitrary - it can be anything. In any case, you can now require that the submodule in another module gain access to private bindings:
#lang racket (require rackunit (submod "a.rkt" for-testing)) (check-true (space?
This is a safer way to identify identifiers from modules without exposing them to all consumers.
source share