I don't think you can directly test an inner procedure while keeping your
test code separately loadable (e.g. different file or module). It doesn't
seem like a good idea to me, personally. Inner procedures communicate to me
that I can change, reorganize, delete, and otherwise do whatever I want to
them without breaking any code outside the definition of the outer
procedure. Breaking tests in a different file with a refactoring of an
inner procedure would be *very *surprising to me.
Instead, I recommend not using inner procedures so extensively. Instead
define functions within modules (or possibly submodules) and use `provide`
with `contract-out` to declare which functions make the public API of your
module. You can then add a test submodule which has access to the inner
workings of the outer module and test "private" helper functions that way.
Here's an example:
#lang racket;; note that using #lang implicitly creates a module around the
whole file
(provide
(contract-out
[my-public-function (-> input? output?)]))
(define (my-public-function input)
(helper2 (helper1 input)))
(define (helper1 input) ...)
(define (helper2 input) ...)
(module+ test ;; inside this submodule we can see helper1 and helper2, even
though they're not provided
(require rackunit)
(check-equal? (helper1 test-input) test-output)
... more tests here ...)
--
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.
