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

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

Reply via email to